[swift-server-dev] Prototype of the discussed HTTP API Spec

[Chris Bailey]

> My assumption was always that this provides a standard 
> server implementation which higher level frameworks can build upon. 
> It wouldn’t do middleware, Zope or WebObjects style processing, but 
> it would definitely do all the HTTP server stuff. SSL, HTTP/2, 
> eventloop etc. What `httplib` does in Python or `http` in Go. The 
> user can just import the Swift module and off he goes. It's the 
> standard Swift way to do HTTP servers and it is built in.

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.

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.

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.

Chris

swift-server-dev-bounces at swift.org wrote on 01/06/2017 21:41:24:

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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170601/4aa2558b/attachment.html>