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

Helge Heß me at helgehess.eu
Tue May 30 07:47:43 CDT 2017

On 30 May 2017, at 13:23, David Ask via swift-server-dev <swift-server-dev at swift.org> wrote:
> David here, working with Paulo on Zewo and more. There’s absolutely a lack of process, as Paulo mentioned. We have a very rough road ahead of us, with a ton of extra work, if we need to start writing implementation code at this level. Tests and dummy implementations should be well enough to allow us to gather feedback.

Personally I don’t think that tests and dummies are sufficient to the viability and performance of the API.

> The way forward, as I see it, is agreeing on the API for HTTP Request/Response/Headers/Method/Status/Version based on a proposal structure and pull requests.

I would prefer the way it works/worked with Swift itself. An initial, working implementation is provided (Swift 1). Then we iterate over it using proposals/pull requests.

As mentioned I agree that it would be helpful to decouple the API setup from the implementation (my branch suggestion). Though it is so little code, I’m not sure it is worth the effort.

> I should also mention that I strongly oppose bringing in dependencies from any actor in the Swift community to the work group org at this stage.

Presumably you are referring to the BlueSocket stuff? I can see your concerns, but I’m sure the idea was just to get forward.

What about a pure Dispatch/CHttp based implementation until the Swift Server Sockets are ready? (where is that effort?)
Would that work for you? It is probably a just a day of work to rip out the Blue stuff and replace it with a basic socket server just using Dispatch ...


-------------- 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/20170530/c008b53a/attachment.sig>

More information about the swift-server-dev mailing list