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

[Carl Brown]

> On May 26, 2017, at 6:07 PM, Paulo Faria via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> Hi, Carl!
> 
> I honestly think the code is too overwhelming.

I can see that.  It was important to us to get something that actually worked end-to-end, could be profiled and had test coverage.  We couldn't get it much smaller.

> I'm also a bit confused about the IBM dependencies. Is this supposed to stay in the swift server repos or is it just momentary so we have working code?

It's a stand-in until the Transport part of the working group has a reference implementation of a socket/stream API and the Security part of the working group has a reference implementation of SSL/TLS. The HTTP part of the group is just ahead of everyone else.

> I'm not very fond of the first option if it is the case, and about the second option... If it's just to see working code.. Then we should have in swift server org only the HTTP module and then have the actual implementation of the framework reside elsewhere importing HTTP module as a dependency. This way we have an view of how people will import and use the framework. It also gives the other frameworks a chance to implement their solutions on top of the common HTTP module.

What do you mean by "the framework" here?  I can think of several things that could be referred to by that phrase, and I'm not sure which one you mean.

> I think we should start moving small bits of code, for example, Version, Headers, Message, Request and Response. After we have that code in the repo working with all the frameworks which are validating the API, then we move on to the body (which is probably going to be the hardest part to settle for everyone). After that we go to the parser/serializer.

Again, I'm not sure what you mean by "the frameworks" here, but putting that aside, there's the issue of timing.  I can see value in asking the group for comments on a small piece of code and not moving on to the next small piece until after everyone has had a chance to comment, but given the pace of progress that's been made by this group so far, don't you think that would take a very, very long time?

-Carl

> On 26 May 2017 at 19:51, Helge Heß via swift-server-dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> wrote:
> Hi Carl,
> 
> > But the question of the moment (for you and for the group) is - do you think this is a good enough starting point for us to move it to the https://github.com/swift-server/ <https://github.com/swift-server/> organization and start iterating via GitHub issues & Pull Requests, or do you think we're still at the stage where we need to have more email discussions about it before we're ready to take that step?
> 
> that seems perfectly reasonable to me.
> 
> What I personally would like best is submitting Johannes’ proposal first, and on top of that submit your changes (w/ explanations what you changed and why in the commits).
> 
> I have Johannes’ original proposal in code over here, in case you need it as a basis:
> 
>   https://github.com/ApacheExpress/ApacheExpress/tree/s3wg-api-proposal-1/S3WGAPIProposal1 <https://github.com/ApacheExpress/ApacheExpress/tree/s3wg-api-proposal-1/S3WGAPIProposal1>
> 
> hh
> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170526/86b9d17c/attachment.html>