[swift-server-dev] HTTP API: prototype review process - prototype now live in "develop"

[Chris Bailey]

As promised, I've moved the code over from carlbrown/HTTPSketch to 
swift-server/http into a "develop" branch:
        https://github.com/swift-server/http/tree/develop

There's been three minor changes:
I've updated the licence to match the Swift.org licence and added 
copyright headers
I've added a API.md file to describe what the current API in the branch is
Carl has moved SimpleResponseCreator into Tests

The next step is to go through a staged review. As its WWDC/AltConf/etc 
next week a number of people will be busy, as such it doesn't make sense 
to have a strict schedule until after next week. Having said that, we 
should try to make progress and close down/agree on some of the types if 
we can. 

Paulo:  As an relatively small starting point, do you want to raise a PR 
to discuss making HTTPVersion a struct?

If can close that down it might make sense to then move onto HTTPMethod 
and HTTPResponseStatus/HTTPStatus as those are again relatively small and 
we might be able to close them out during the busy week.

Chris




From:   Chris Bailey via swift-server-dev <swift-server-dev at swift.org>
To:     <swift-server-dev at swift.org>
Date:   30/05/2017 19:13
Subject:        [swift-server-dev] HTTP API: prototype review process
Sent by:        swift-server-dev-bounces at swift.org



I've had some discussions with Paulo and David Ask offline, and below is 
the proposal from Paulo on how we proceed: 
Move the HTTP Sketch prototype (of Johannes' API proposal) into the 
swift-server repo
This will go into a “develop” branch rather than "master", but will have a 
MVP semver tag so it can be included via SwiftPM for people to test and 
benchmark with. 
Have a staged review of the types and APIs
In order to make sure that we have full "review coverage", we'll structure 
reviewing and reaching agreement on the types and APIs, including having 
deadlines for discussion, updates and reaching a conclusion. 
Reviewed types and APIs are then merged into master
Once a set of types or APIs have been reviewed, AND they build, pass tests 
with at least (95%?) coverage, 100% doc coverage, have generated jazzy 
docs and as well as design docs including the rationale for design 
decisions. 
When the full set of types and APIs have been reviewed and merged to 
master, raise a Swift Evolution Proposal
Once there is a full implementation in master, the API spec will go 
forward as a Swift Evolution Proposal to get feedback from the wider 
community. Once the feedback from the community is included, we can look 
at tagging a 1.0.0 release based on master.

We'll also document the API separately etc as suggested by Helge Heß. If 
this seems like a reasonable approach, we'll move the prototype code over 
to the swift-server org into a "develop" branch tomorrow. 

Chris
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170531/1902492a/attachment.html>