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

[Paulo Faria]

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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170527/3be035fa/attachment.html>