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

[Carl Brown]

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> 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 (Work)
Austin, TX


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