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

[Michael Chiu]

Hi Carl,

I feel the same way as you feel. 

I have no mean to have everybody start the discussion again :).

 What I mean is that we should pick one architecture, either yours xor Paulo’s, and start work on it (on github) component by component, as Paulo suggested. 

The reason why I’m mentioning architecture is that unlike your proposal, Paulo’s Req/Res are confirming to the Message protocol, so now we have to think what the protocol, Message should actually be if we pick Paulo’s. that says if we pick a different base, the components we’re going to discuss later on github will be different.

Hi everyone, 

Personally, This is how I feel comparing two proposals:

I like how HTTPHeaders work on Paulo’s side, since it is implemented as ExpressibleByDictionaryLiteral, I can imagine providing a list-like data structure can provide functionality of a [Key: [Values]] in a memory friendly way.

On Carl's proposal, I think HTTPResponseWriter is a bit obsoleted, I think the req/res itself are capable to contains session info if we add a session-id property and bitmap flag to the req/res, In that cause, I think it can simplify the ownership model (just a thought, no prove provided).

On the Paulo side the Async/Sync read/write is a bit strange to me, and it doesn’t quite show how is it necessary. Since if we are providing api to mutate the body of a req/res, explicitly making a AsyncBody enum is a bit over engineered for me.

I like the RequestMethod and ResponseStatus on Carl’s side better, since it is implemented as enum and hence easily for user to use in a switch statement.

On Paulo's IO side, Duration sounds real cool to me but that should be the stream-side’s responsibility.

HTTPTransferEncoding is a big plus on Carl’s side.

TL;DR:

I think there’s some cool stuff on both side that can mix and match. I think we should just pick a base and work on it. 

Michael.

 
> On May 26, 2017, at 9:21 PM, Carl Brown <carl.brown.swift at linuxswift.com <mailto:carl.brown.swift at linuxswift.com>> wrote:
> 
> Hi, Paulo and Michael,
> 
> I’ll be honest, this feels counterproductive to me.  Folks on this list already spent weeks discussing that API proposal starting on Friday, Mar 24th (https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000329.html <https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000329.html>) and going until the discussion died out on Wednesday, April 12th (https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170410/000450.html <https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170410/000450.html>).
> 
> That’s not to say the API should now be locked in stone, but it just doesn’t seem useful to me at this point to throw all that discussion away, start over from scratch and not even plan to have something we can start implementing any time soon.
> 
> Am I the only one who feels that way?
> 
> -Carl
> 
> 
>> On May 26, 2017, at 8:04 PM, Michael Chiu <hatsuneyuji at icloud.com <mailto:hatsuneyuji at icloud.com>> wrote:
>> 
>> 
>> 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 <mailto: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.
>>> 
> 
> -- 
> Carl Brown, Swift at IBM
> Carl.Brown1 at IBM.com <mailto:Carl.Brown1 at IBM.com> (Work)
> Austin, TX

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