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

[Chris Bailey]

Hi Paulo:

One of the things we're trying to avoid is a waterfall design approach, 
requiring a fully settled API before any implementation work starts - its 
much more preferable to have a reasonable starting point, make it work, 
and then make it better. One of the advantages of this approach is that it 
widens the funnel of participation out from "API designers" to include 
users, who can try out the API and provide feedback.

The proposal that's been implemented was the result of a number of weeks 
of debate on the mailing list, and as such gives us that starting point. 
That doesn't mean that your proposal is ignored - in fact it gives us an 
excellent list of areas that we can debate incrementally and see what the 
effect would be via working use cases and performance tests.

That then gets us working and collaboration on on a single code base - 
which is really the primary goal of the workgroup!

Chris



From:   Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
To:     Michael Chiu <hatsuneyuji at icloud.com>
Cc:     swift-server-dev <swift-server-dev at swift.org>
Date:   27/05/2017 12:06
Subject:        Re: [swift-server-dev] Prototype of the discussed HTTP API 
Spec
Sent by:        swift-server-dev-bounces at swift.org



Sorry if I'm being annoying, but I really feel what we lack is process. 
There's no formal proposal and proposal review. I really think we should 
move incrementally with well defined scopes and deadlines for every round. 
We didn't have that so far. Carl and others said that my suggestion is 
counter productive. I think the opposite, of course, as what I'm proposing 
is a well defined process where when we settle on a design for a 
particular set of base APIs then we move on to a higher absctraction. This 
way we won't be discussing the same things over and over again. I'll 
repeat, if we can't agree on the base types how can we move on? I'm saying 
let's first *settle* on Version, Headers, Message, Request and Response. 
Really *define* the API so then we move on, incrementally, from lower 
abstraction to higher abstraction. 



On May 27, 2017 07:53, "Paulo Faria" <paulo at zewo.io> wrote:
I'm just proposing we move the code incrementally. The "most consentual" 
list I sent yesterday isn't radically different from the code Johannes 
proposed. I really don't want to discuss this over and over, ad infinitum. 
The most important in the messages I sent before is that we need a well 
defined process. We don't have it. Just taking the first implementation, 
with a lot of things that admitedly don't fit the scope, and adding that 
so we can rework doesn't feel right to me. I'm actually confused about the 
scope this project is taking. The code there explicitly mentions a WebApp, 
which is a higher responsibility than HTTP. When we started this project 
the scope as very clear. Crypto/TLS, Socket, HTTP. A well designed HTTP 
module shouldn't depend *at all* on the socket implementation. Providing 
an implementation would be just a matter of injecting a dependency. Moving 
that code as is to the org really doesn't feel right to me. All I'm saying 
is that we definitely should start having code on the org. But I say we 
move first Version, Headers, Message, Request, Response. And again, the 
"least controversial" I sent yesterday isn't radically strange. It's an 
evolution of Johaness original proposal, plus Carl's, plus Helge's 
suggestions, plus my suggestions. The only thing I added that wasn't 
discussed before is HTTPHeader.Field which does a case insensitive 
comparison in its equatable implementation, and the Message protocol which 
holds the properties common to request and response (version and headers). 
If we can't agree on that, which is the sum of everything that was 
discussed about these particular types. How can we agree on that full 
implementation?

On May 27, 2017 05:13, "Michael Chiu" <hatsuneyuji at icloud.com> wrote:
Hi Carl


>       This email thread isn’t about an API proposal. It’s about a 
prototype implementation of an API that was already proposed and discussed 
a month and a half ago.  The prototype isn't a full-featured framework 
like Vapor or Kitura, but it does actually work and it even has XCTests 
with decent (>75%) code coverage.

I see, I was confused by the email contents instead of reading the subject 
and thought we are finally implementing some code. TBH, I don’t see any 
reason why this should not move to swift-server on github, It sounds a 
good start to me.
Thank you guys’ hard work for building it.

>       Also, please note that I didn’t play any part in proposing this 
API back in March/April - it’s not “Carl’s proposal.”  I just took the 
existing API that the group had previously discussed and implemented 
enough of it so that we could measure the utility and performance of the 
API as proposed and so that we could have better informed discussions 
about potential alternatives.

You’re right. it was Johannes’ proposal, I’m so sorry for that.

Michael.

_______________________________________________
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/20170530/9ccfc5d1/attachment.html>