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

[Johannes Weiss]

Hi Rien,

> On 1 Jun 2017, at 7:43 pm, Rien <Rien at Balancingrock.nl> wrote:
> 
>> 
>> On 01 Jun 2017, at 19:36, Michael Chiu via swift-server-dev <swift-server-dev at swift.org> wrote:
>> 
>> Hi Johannes and Paulo
>> 
>>>> I think what Michael means is that we must allow other frameworks based on libdispatch/libuv/libdill/libwhatever to implement their approach too. And this means providing synchronous APIs for the base IO and exposing the file descriptor so people can choose how they are going to poll/schedule for reads and writes. I agree with him a 100%.
>>> 
>>> but the base APIs are orthogonal to the HTTP API, right? The HTTP API is implemented using some underlying mechanisms, be it libdill/mill/venice, kevent/epoll, Apache, Perfect-Net, DispatchSource, or DispatchIO. But as you say, that's a detail.
>> 
>> Actually I think the HTTP API won’t need to use any of libdispatch/libuv/libdill, despite HTTP2 has quite a lot of layer violations.
>> 
>> What I think will be great is a input driven parser, so instead of the the HTTP library actively reading data from the IO side, the IO side feed the parser with data like how nodejs’ http parser does.
>> 
> 
> 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.


> But I think you are right: an input driver parser is probably that with which most people are familiar, and it can probably be used to cover upwards of 90% of all use cases?
> 
> I don’t have a generic use case. My use case is to replace “wordpress”. I want to create websites where the website is basically an App. For that I needed an HTTP(s) server.
> 
> What I did; I first build a socket layer, then a server, and added in SSL and multiple domain support. So then I had a fully functional server that accepts requests and uses callbacks to process the received data.
> Nothing of this has anything to do with HTTP. (Yes, asynch, event driven etc, uses only Swift, Posix calls all the way and DispatchQueue’s no 3thrd party libs except openSSL)
> 
> Then I took the ‘connection’ object from the server layer and created an HTTP connection around it. All very traditional. There may be use cases out there that want to process a connection’s data asap, but so far I only process fully received HTTP requests. When complete, the HTTP requested is handed off (another dispatch queue) to be processed by the ‘worker thread’. If more HTTP requests arrive from the same client, they are queued until the worker thread has time to process the next request. The worker thread processes everything in the order it was received. Transmission (replies) may be initiated at any time (by the worker thread). Either transmit and wait, or buffered transfer (fire & forget).
> 
> To me, this looks all very traditional. And I find it hard to try and match it to anything here discussed.
> 
> I did take a look at the proposed API and tried to see how I could adopt it. To no avail. I do not think this is usable by me (at least not the way it looks now).
> 
> I do like the idea of using standards. Thus if this mailing list comes up with something that I can use, I will probably rewrite some of my code and adopt it.

Thanks for contributing that, we should make sure that setups as you describe can be implemented with whatever API we come up with. Would you be able to post your HTTP APIs using which your web apps are implemented? Then we can see what the current proposal is missing and amend the API.

From a first quick read of what you describe I don't see anything that sounds totally incompatible but I might be missing something.


Thanks,
  Johannes

> 
> 
> 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
> 
> PS: With my ‘traditional’ approach the typical turn around for a static website lookup is approx 1ms per request (MacMini, SSD)
> 
> The server runs at www.overbeterleven.nl:6678 (HTTP only I have not yet installed a certificate)
> The site is in Dutch, sorry. But that is not important as the site is currently used to test my server.
> I call my server Swiftfire, see above. In the next week or so I will probably run www.swiftfire.nl also using Swiftfire.
> 
> I have progressed beyond the HTTP server, Each domain implements a stack of ‘services’ (that can be unique for that domain). The default stack implements a static website server.
> Then I added “function calls” to the web pages themselves. Such that when the server returns a page, it will scan the page and replace any ‘function call’ with generated HTML code.
> This makes dynamic sites possible.
> Now I am working on a small Html library to make the generation of Html code from within Swift easier. Should be ready next week or so.
> 
>> Michael
>> 
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-server-dev