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

[Rien]

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