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