[swift-server-dev] Next HTTP API meeting

[Johannes Weiß]

Hi Helge,

> On 30 Mar 2017, at 15:31, Helge Heß <me at helgehess.eu> wrote:
> 
> On 29 Mar 2017, at 19:14, Johannes Weiß <johannesweiss at apple.com> wrote:
>> As per my email where I sketch what we use internally, we only have an async API. We have higher-level stuff on that and some does actually have sync APIs but why do you think we need both a sync and an async API? If someone wants a sync web framework, that's pretty simple to put on top of an async API. So I'd argue we should only have an async API for the HTTP stuff this group proposes.
> 
> OK, so I thought I play being a stakeholder (“They are responsible ... to adopt the new APIs into their frameworks") and actually do a test implementation of your API proposal ;->
> 
> You can find it here:
> 
>  https://github.com/AlwaysRightInstitute/mod_swift/tree/s3wg-api-proposal-1
> 
> should run out of the box, you don’t need anything extra. This is driven by a synchronous HTTP server.

wow, that is pretty cool!


> Personally I find the API a little weird (because the response/request ordering is backwards in the source) :-). But we have to get started somewhere.
> 
> Notes:
> 
> - In this implementation it would have been helpful if at least
>  `HTTPHeaders` would be a protocol. The way it is setup now I
>  essentially have to always copy all the data.

agreed, good point


>  - since it is completely immutable, it wouldn’t matter whether
>    this is done as a struct or class (apart from perf characteristics)
>  - the way it is done now, a lot of copying goes on when the
>    request is passed around, but I suppose that could be removed
>    by the Swift 7.1 optimiser
> 
> - the API uses @escaping callbacks, which for this imp would not
>  be necessary. Presumably one could reduce the overhead using
>  the new `withoutActuallyEscaping`, but that would make the
>  user level code look really weird

agreed, that's a price we would need to pay


> - my other comments about using `enum` in public APIs, specifically
>  HTTPMethod. IMO that at least needs .custom.

no problems with that at all. The reason it currently doesn't have that is that our internal thing uses http_parser.c which only allows those methods.


> - HTTPResponseWriter is OK, but I guess I would really separate
>  out the write functions in a WriteStream which would be HTTP
>  agnostic
> 
> 
> But how would I convert that into a synchronous framework API (w/o reading everything into memory or resorting to a secondary queue?). Similar to this:
> 
>  serve { req, res in
>    res.writeResponse(status: .ok, transferEncoding: .chunked)
> 
>    while let data = req.read() {
>      res.write(data)
>    }
>    res.end()
>  }
> 
> There would need to be a way to pass back the control from the generating side to the consuming one?

the only way that I can see this working with the current proposal is to have a queue of chunks that req.read() takes items off (and blocks if none available) and the body processor enqueues into when they become available.


> [...]

-- 
  Johannes