<font size=2 face="sans-serif">Hi Paulo:</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">That then gets us working and collaboration
on on a single code base - which is really the primary goal of the workgroup!</font>
<br>
<br><font size=2 face="sans-serif">Chris</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Paulo Faria via swift-server-dev
<swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Michael Chiu <hatsuneyuji@icloud.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">swift-server-dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">27/05/2017 12:06</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
Prototype of the discussed HTTP API Spec</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">swift-server-dev-bounces@swift.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>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. </font>
<br>
<br>
<br>
<br><font size=3>On May 27, 2017 07:53, "Paulo Faria" <</font><a href=mailto:paulo@zewo.io><font size=3 color=blue><u>paulo@zewo.io</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>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?</font>
<br>
<br><font size=3>On May 27, 2017 05:13, "Michael Chiu" <</font><a href=mailto:hatsuneyuji@icloud.com target=_blank><font size=3 color=blue><u>hatsuneyuji@icloud.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>Hi Carl<br>
<br>
<br>
> 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.<br>
<br>
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.<br>
Thank you guys’ hard work for building it.<br>
<br>
> 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.<br>
<br>
You’re right. it was Johannes’ proposal, I’m so sorry for that.<br>
<br>
Michael.<br>
<br>
</font><tt><font size=2>_______________________________________________<br>
swift-server-dev mailing list<br>
swift-server-dev@swift.org<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>