<tt><font size=2>> My assumption was always that this provides a standard
<br>
> server implementation which higher level frameworks can build upon.
<br>
> It wouldn’t do middleware, Zope or WebObjects style processing, but
<br>
> it would definitely do all the HTTP server stuff. SSL, HTTP/2, <br>
> eventloop etc. What `httplib` does in Python or `http` in Go. The
<br>
> user can just import the Swift module and off he goes. It's the <br>
> standard Swift way to do HTTP servers and it is built in.</font></tt>
<br>
<br><font size=2 face="sans-serif">This was, and I believe still is, the
goal of the Server APIs Project - to provide core foundational capabilities,
initially scoped to networking, security and HTTP libraries.</font>
<br>
<br><font size=2 face="sans-serif">In some areas this means we have to
make hard decisions about what we believe is right for the Swift ecosystem
- which does require some guesswork about the future. Concurrency models
is one area that has come up a number of times, and is one of the reasons
we had a long period of open discussion before moving to looking at the
API surface.</font>
<br>
<br><font size=2 face="sans-serif">All the indications are that the ongoing
concurrency model for Swift will be async. The current implementation is
Dispatch based async, and a large amount of the existing Swift APIs rely
on this approach. That's not to say that Swift 5 couldn't bring a blocking
/ CSP style concurrency model - but if that happens there will need to
be a migration path for the existing async APIs, so the Server APIs Project
libraries won't be alone in that.</font>
<br>
<br><font size=2 face="sans-serif">Chris</font>
<br>
<br><tt><font size=2>swift-server-dev-bounces@swift.org wrote on 01/06/2017
21:41:24:<br>
<br>
> From: Helge Heß via swift-server-dev <swift-server-dev@swift.org></font></tt>
<br><tt><font size=2>> To: Paulo Faria via swift-server-dev <swift-server-dev@swift.org></font></tt>
<br><tt><font size=2>> Date: 01/06/2017 21:48</font></tt>
<br><tt><font size=2>> Subject: Re: [swift-server-dev] Prototype of
the discussed HTTP API Spec</font></tt>
<br><tt><font size=2>> Sent by: swift-server-dev-bounces@swift.org</font></tt>
<br><tt><font size=2>> <br>
> Hi,<br>
> <br>
> > On 1. Jun 2017, at 21:07, Johannes Weiss via swift-server-dev
<br>
> <swift-server-dev@swift.org> wrote:<br>
> >> I have to admit that I tried to follow the discussion here,
but I<br>
> got lost. I do not see what all this asynch/kevent/... stuff has to
<br>
> do with an HTTP API.<br>
> >> <br>
> >> Its probably me though. It happens… :-(<br>
> > <br>
> > As one of the main offenders I can tell you that I don't quite
<br>
> understand it either.<br>
> <br>
> yes, the discussion drifted off and is a little lost in arguments.
<br>
> But I don’t think it is actually hard to understand at all.<br>
> <br>
> There are two main opinions:<br>
> A) there should be a callback based API only (Johannes)<br>
> B) there should be a synchronous API too (Paulo)<br>
> <br>
> If this effort goes with just A, I think it is kinda obvious that
<br>
> this won’t work for frameworks with a synchronous API. Not because
<br>
> it isn’t possible to implement it at all (I showed that it is w/
the<br>
> Apache one), but because it isn’t possible to implement in a way
<br>
> which aligns with the higher level synchronous APIs of the <br>
> frameworks (which are not callback based and don’t want to be callback
based).<br>
> <br>
> <br>
> To resolve the situation one option would be to completely leave out<br>
> the relevant parts and just have the parser, the request/response
<br>
> objects. And other stuff working just on top of that (e.g. cookies
<br>
> have been mentioned, auth decoding, utility stuff like that).<br>
> Talking API.md:<br>
> <br>
> </font></tt><a href=https://github.com/modswift/http/blob/develop/API.md><tt><font size=2>https://github.com/modswift/http/blob/develop/API.md</font></tt></a><tt><font size=2><br>
> <br>
> Essentially remove: HTTPBodyHandler, HTTPBodyProcessing, HTTPBodyChunk.<br>
> They could still be used in a Dispatch based default implementation,<br>
> but wouldn’t be ‘standard API’. But add: HTTPParser.<br>
> <br>
> <br>
> I think the *goal* of this group is a little mixed up or maybe <br>
> unclear. My assumption was always that this provides a standard <br>
> server implementation which higher level frameworks can build upon.
<br>
> It wouldn’t do middleware, Zope or WebObjects style processing, but
<br>
> it would definitely do all the HTTP server stuff. SSL, HTTP/2, <br>
> eventloop etc. What `httplib` does in Python or `http` in Go. The
<br>
> user can just import the Swift module and off he goes. It's the <br>
> standard Swift way to do HTTP servers and it is built in.<br>
> If he then wants fancy HTML templates, an integrated ORM and stuff
<br>
> like that, he’d use a framework build on top of that basic lib.<br>
> This IMO definitely implies that an I/O model and all that is chosen<br>
> for the user.<br>
> <br>
> On the other side people like Paulo (I think ;-) see the API more
<br>
> like just that, a common AP*Interface*. Only the common API is <br>
> shared, everyone still has his own ’server' and eventually code on
<br>
> top of that is shared. Kinda the other way around.<br>
> <br>
> So maybe the common goal should be clarified (or found) one more <br>
> time. Or maybe I’m just completely wrong :-)<br>
> <br>
> hh<br>
> <br>
> P.S.: Some of my personal opinions, just to give some context, no
<br>
> need to discuss them at all:<br>
> - It would be great if Swift would have a HttpServer lib which you<br>
> can just use<br>
> - If such exists it would be only confusing to provide two different<br>
> APIs (in fact the other approaches may just die adoption wise
as<br>
> the standard, well, sets the standard :-)<br>
> - In general I’m mostly in favour of using async for the standard<br>
> module (despite what follows)<br>
> - I think that async APIs are overrated. They are a must on very <br>
> highly scalable systems of certain kinds, but for many many
types<br>
> of deployments they are just not necessary.<br>
> - For most people programming against async APIs is a<br>
> pain in the **, particularly w/ ARC. It just raises the complexity
a<br>
> lot. (which people then try to solve w/ more additional magic
like<br>
> Promises)<br>
> - Node.js changed that a little, but the far majority of web<br>
> development is still done in traditional synchronous/threaded<br>
> setups: WebObjects, PHP, Servlets, Rails. IMO for a good reason,
<br>
> see above.<br>
> - If you use an async API and people end up doing `concat`, which<br>
> is really common in Node .., you gained, well, nothing.<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><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>