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

Fri Jun 2 02:29:47 CDT 2017

> On 02 Jun 2017, at 09:22, Chris Bailey <BAILEYC at uk.ibm.com> wrote:
> 
> > Personally I would favour a solution in which the user code is not 
> > activated until the request header is complete. Then the user code 
> > can decide (with the request header provided) if it needs the entire
> > body at once, or if it wants to process the body in chunks. — in 
> > fact, I think I will improve Swiftfire to do just that ;-) 
> 
> Isn't that possible in framework built on top of the HTTP proposal? The framework can decide whether to read the full request, including body and trailers, and convert that into a fully formed request before carrying out routing and passing it on to application code, or whether to pass headers plus stream. 
> 
> Chris
> 

I may be loosing track of which proposal you are referring to, but looking at 
https://github.com/swift-server/http/blob/develop/Sources/SwiftServerHttp
that certainly seems possible.

Rien.

> 
> swift-server-dev-bounces at swift.org wrote on 02/06/2017 08:03:43:
> 
> > From: Rien via swift-server-dev <swift-server-dev at swift.org> 
> > To: Helge Heß <me at helgehess.eu> 
> > Cc: Paulo Faria via swift-server-dev <swift-server-dev at swift.org> 
> > Date: 02/06/2017 08:03 
> > Subject: Re: [swift-server-dev] Prototype of the discussed HTTP API Spec 
> > Sent by: swift-server-dev-bounces at swift.org 
> > 
> > Ah, I think I am starting to understand now.
> > Basically the problem is: What to do with A) Very large HTTP bodies,
> > and B) In exotic applications that need extreme scalability
> > While I think that A is something that must be considered, I think 
> > that B is something that is probably more easily solved by a 
> > specific targeted API. Or maybe even no API, after all, I would 
> > expect these kind of applications to have additional considerations 
> > that make it almost impossible to use a  general purpose (GP) API - 
> > at least it would make such a GP API incomprehensible for mortal 
> > developers. And let’s be honest, if we have to develop such an 
> > exotic beast then the additional effort to create a custom API 
> > building on Posix is probably lost in the fringes anyhow.
> > 
> > But it is right to make that decision early on.
> > 
> > Why not make two proposals and see which one receives the most support?
> > 
> > Personally I would favour a solution in which the user code is not 
> > activated until the request header is complete. Then the user code 
> > can decide (with the request header provided) if it needs the entire
> > body at once, or if it wants to process the body in chunks. — in 
> > fact, I think I will improve Swiftfire to do just that ;-)
> > 
> > Regards,
> > Rien
> > 
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Balancingrock
> > Project: http://swiftfire.nl - A server for websites build in Swift
> > 
> > 
> > 
> > 
> > 
> > 
> > > On 01 Jun 2017, at 22:41, Helge Heß via swift-server-dev <swift-
> > server-dev at swift.org> wrote:
> > > 
> > > 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
> > 
> > _______________________________________________
> > 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