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

[Paulo Faria]

> 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> wrote:

>
> 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> 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/ 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
>>
>> hh
>>
>>
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev at swift.org
>> 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/b3bce1aa/attachment.html>