<div dir="ltr">> <span style="font-size:12.800000190734863px">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.</span><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">I see this project as both, a base for all other frameworks based on libdispatch/libdill/libuv/libwhatever, *AND* a default implementation </span><span style="font-size:12.800000190734863px">(based on libdispatch)</span><span style="font-size:12.800000190734863px"> with everything up to the HTTP server and client which people can just import and use for simple use cases. The goal of this project as far as we conceived it before starting is *NOT* to provide a high level framework with routers, middleware, etc. So higher level frameworks like Kitura, Vapor, Perfect, Zewo, etc will always be desired for more complex applications. </span><span style="font-size:12.800000190734863px">At least that's what was discussed by the core members when we were setting up this work group. </span><span style="font-size:12.800000190734863px">Having said that we just can't ignore the existing higher level frameworks. And when we talk about synchronous APIs, Johannes point, which I completely agree, is about the lack of official Swift support for green threads. The problem with that argument is that green threads aren't the only valid way to use synchronous APIs.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Vapor, for example, which is one of the most used frameworks nowadays, uses blocking synchronous APIs over threads. Yes, this is not very performant, but a whole lot of other extremely popular frameworks written in other languages are (or were at some point) blocking. The number of people using Vapor speaks for itself. We just *can't* ignore them. If that concurrency model is enough for their use case. We just can't simply ignore them.</span><br></div><div><br></div><div><span style="font-size:12.800000190734863px">So, in my view, the ideal would be to support both async and sync APIs, and the default implementation that we'll provide with this project should be asynchronous using libdispatch.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Of course we could just say F*@#$ you to all of the other approaches and only implement a single approach, but I think we can do better than this.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 June 2017 at 17:41, Helge Heß via swift-server-dev <span dir="ltr"><<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
> On 1. Jun 2017, at 21:07, Johannes Weiss via swift-server-dev <<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> wrote:<br>
>> 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.<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 understand it either.<br>
<br>
</span>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.<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 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).<br>
<br>
<br>
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).<br>
Talking API.md:<br>
<br>
<a href="https://github.com/modswift/http/blob/develop/API.md" rel="noreferrer" target="_blank">https://github.com/modswift/<wbr>http/blob/develop/API.md</a><br>
<br>
Essentially remove: HTTPBodyHandler, HTTPBodyProcessing, HTTPBodyChunk.<br>
They could still be used in a Dispatch based default 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 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.<br>
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.<br>
This IMO definitely implies that an I/O model and all that is chosen for the user.<br>
<br>
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.<br>
<br>
So maybe the common goal should be clarified (or found) one more 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 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>
<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>