[swift-server-dev] Next HTTP API meeting

[Helge Heß]

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.

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.
  - 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

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

- 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?


Any other proposals I should try? :-)

hh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170330/233ad840/attachment.sig>