<tt><font size=2>> 1)<br>
> One thing I would like to see is a separate item in the repository
that contains just the actual API. Instead of the API intermingled with
the > concrete implementation. Similar to what Johannes’ did. Could
be a document called API.md.<br>
> Update this when the API changes due to workgroup work.</font></tt>
<br>
<br><font size=2 face="sans-serif">Which would be more preferable, a full
Jazzy-built API doc, just a .md file or both? I'd prefer not to take the
multi-branch approach if possible, if nothing else because of the difficulty
in keeping the branches in sync. We should be able to propose implementation
changes via PRs that people can clone, test and compare, and we can merge
in what makes sense - removing blue-socket is a good example.</font>
<br><tt><font size=2><br>
<br>
> 2)<br>
> The other thing that would be nice is a demo tool in the Sources directory,
again similar to what Johannes showed (his tiny echod sample).</font></tt>
<br>
<br><font size=2 face="sans-serif">It looks like Carl has done that already
in SimpleResponseCreator.swift:</font>
<br><font size=2 face="sans-serif"> </font><a href=https://github.com/carlbrown/HTTPSketch/blob/master/Sources/HTTPSketch/SimpleResponseCreator.swift><font size=2 color=blue face="sans-serif">https://github.com/carlbrown/HTTPSketch/blob/master/Sources/HTTPSketch/SimpleResponseCreator.swift</font></a>
<br><font size=2 face="sans-serif">Giving it a more obvious name makes
sense - along with documenting it in the README.md, etc.</font>
<br>
<br><font size=2 face="sans-serif">Chris<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Helge Heß via swift-server-dev
<swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">swift-server-dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">30/05/2017 11:54</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
Prototype of the discussed HTTP API Spec</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">swift-server-dev-bounces@swift.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hi,<br>
<br>
+1 on Chris’ comment.<br>
<br>
Two wishes:<br>
<br>
1)<br>
One thing I would like to see is a separate item in the repository that
contains just the actual API. Instead of the API intermingled with the
concrete implementation. Similar to what Johannes’ did. Could be a document
called API.md.<br>
Update this when the API changes due to workgroup work.<br>
<br>
Or more fancy: Put just the API (and no2 below) into the master branch.
The same .swift files, just w/o any implementation code. (Yes, this won’t
compile of course). Then have branches for concrete implementations, say
‘blue-socket’ for the current one.<br>
This way the API can evolve in master and you can always see where the
concrete implementation is at, and other people can contribute different
implementations for comparison (e.g. the low hanging fruit would be a simple
one that doesn’t require a socket library but just libdispatch).<br>
<br>
2)<br>
The other thing that would be nice is a demo tool in the Sources directory,
again similar to what Johannes showed (his tiny echod sample).<br>
<br>
hh<br>
<br>
> On 30. May 2017, at 12:08, Chris Bailey via swift-server-dev <swift-server-dev@swift.org>
wrote:<br>
> <br>
> Hi Paulo: <br>
> <br>
> One of the things we're trying to avoid is a waterfall design approach,
requiring a fully settled API before any implementation work starts - its
much more preferable to have a reasonable starting point, make it work,
and then make it better. One of the advantages of this approach is that
it widens the funnel of participation out from "API designers"
to include users, who can try out the API and provide feedback. <br>
> <br>
> The proposal that's been implemented was the result of a number of
weeks of debate on the mailing list, and as such gives us that starting
point. That doesn't mean that your proposal is ignored - in fact it gives
us an excellent list of areas that we can debate incrementally and see
what the effect would be via working use cases and performance tests. <br>
> <br>
> That then gets us working and collaboration on on a single code base
- which is really the primary goal of the workgroup! <br>
> <br>
> Chris <br>
> <br>
<br>
_______________________________________________<br>
swift-server-dev mailing list<br>
swift-server-dev@swift.org<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>