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

[Michael Chiu]

In general I agree this is how we should process, components by components, arguing around implementation detail won’t help much here. 

Tho we do need to agree an architecture to start with before we know what are the components we need.

I do agree that version, req method and res status is something quite orthogonal to the actual architecture hence a good place to discuss ahead.

Michael

> On May 26, 2017, at 4:57 PM, Paulo Faria via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> > 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.
> 
> Sorry, it was really confusing. I meant higher level web frameworks like Kitura, for example. It looks like the code you have go all the way up there.. The WebApp type says it all. I don't think we should have this at all. At least not for now.. I believe we should only go up to the HTTP server/client. I think the types we should implement are in order (naming aside, adding prefixes or not, Sync, Async etc)
> 
> Week 1
> 
> Version
> Headers
> Message
> Request
> Response
> 
> Week 2
> 
> SyncBody
> AsyncBody
> 
> Week 3
> 
> SyncRequestParser
> AsyncRequestParser
> SyncResponseParser
> AsyncResponseParser
> 
> Week 4
> 
> SyncRequestSerializer
> AsyncRequestSerializer
> SyncResponseSerializer
> AsyncResponseSerializer
> 
> Week 5
> 
> SyncServer
> AsyncServer
> 
> Week 6
> 
> SyncClient
> AsyncClient
> 
> We would have one week to discuss each the API of the types in each set. After we decide on the API we implement in the following week while discussing the next set of APIs. Once we settle on the API for each type implementing shouldn't take more than 2 days based on our experience with the subject.
> 
> Using this scheme we would have the API ready in mid-july. What do you guys think? I really think this is a good way to follow on the discussion/implementation.
> 
> 
> 
> On 26 May 2017 at 20:40, Carl Brown <carl.brown.swift at linuxswift.com <mailto:carl.brown.swift at linuxswift.com>> wrote:
> 
>> On May 26, 2017, at 6:07 PM, Paulo Faria via swift-server-dev <swift-server-dev at swift.org <mailto: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 <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/03acd2a3/attachment.html>