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

Chris Bailey BAILEYC at uk.ibm.com
Fri Jun 2 02:22:12 CDT 2017 

> 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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170602/0afb0ff2/attachment.html>

More information about the swift-server-dev mailing list