<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div>In general I agree this is how we should process, components by components, arguing around implementation detail won’t help much here. <div class=""><br class=""></div><div class="">Tho we do need to agree an architecture to start with before we know what are the components we need.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Michael</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 26, 2017, at 4:57 PM, Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">> <span style="font-size:12.800000190734863px" class="">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.</span><div class=""><span style="font-size:12.800000190734863px" class=""><br class=""></span></div><div class=""><span style="font-size:12.800000190734863px" class="">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)</span></div><div class=""><span style="font-size:12.800000190734863px" class=""><br class=""></span></div><div class=""><span style="font-size:12.800000190734863px" class="">Week 1</span></div><div class=""><span style="font-size:12.800000190734863px" class=""><br class=""></span></div><div class=""><span style="font-size:12.800000190734863px" class="">Version</span></div><div class=""><span style="font-size:12.800000190734863px" class="">Headers</span></div><div class=""><span style="font-size:12.800000190734863px" class="">Message</span></div><div class=""><span style="font-size:12.800000190734863px" class="">Request</span></div><div class=""><span style="font-size:12.800000190734863px" class="">Response</span></div><div class=""><span style="font-size:12.800000190734863px" class=""><br class=""></span></div><div class=""><span style="font-size:12.800000190734863px" class="">Week 2</span><span style="font-size:12.800000190734863px" class=""><br class=""></span></div><div class=""><span style="font-size:12.800000190734863px" class=""><br class=""></span></div><div class=""><span style="font-size:12.800000190734863px" class="">SyncBody</span></div><div class="">AsyncBody</div><div class=""><br class=""></div><div class="">Week 3</div><div class=""><br class=""></div><div class="">SyncRequestParser</div><div class="">AsyncRequestParser</div><div class="">SyncResponseParser</div><div class="">AsyncResponseParser</div><div class=""><br class=""></div><div class="">Week 4</div><div class=""><br class=""></div><div class="">SyncRequestSerializer</div><div class="">AsyncRequestSerializer</div><div class="">SyncResponseSerializer</div><div class="">AsyncResponseSerializer</div><div class=""><br class=""></div><div class="">Week 5</div><div class=""><br class=""></div><div class="">SyncServer</div><div class="">AsyncServer</div><div class=""><br class=""></div><div class="">Week 6</div><div class=""><br class=""></div><div class="">SyncClient</div><div class="">AsyncClient</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 26 May 2017 at 20:40, Carl Brown <span dir="ltr" class=""><<a href="mailto:carl.brown.swift@linuxswift.com" target="_blank" class="">carl.brown.swift@linuxswift.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div class="">On May 26, 2017, at 6:07 PM, Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank" class="">swift-server-dev@swift.org</a>> wrote:</div><br class="m_-8462004033862374951Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi, Carl!<div class=""><br class=""></div><div class="">I honestly think the code is too overwhelming. </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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? </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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?</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Carl</div></font></span><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On 26 May 2017 at 19:51, Helge Heß via swift-server-dev <span dir="ltr" class=""><<a href="mailto:swift-server-dev@swift.org" target="_blank" class="">swift-server-dev@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Carl,<br class="">
<span class=""><br class="">
> 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 <a href="https://github.com/swift-server/" rel="noreferrer" target="_blank" class="">https://github.com/swift-serve<wbr class="">r/</a> 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?<br class="">
<br class="">
</span>that seems perfectly reasonable to me.<br class="">
<br class="">
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).<br class="">
<br class="">
I have Johannes’ original proposal in code over here, in case you need it as a basis:<br class="">
<br class="">
<a href="https://github.com/ApacheExpress/ApacheExpress/tree/s3wg-api-proposal-1/S3WGAPIProposal1" rel="noreferrer" target="_blank" class="">https://github.com/ApacheExpre<wbr class="">ss/ApacheExpress/tree/s3wg-<wbr class="">api-proposal-1/S3WGAPIProposal<wbr class="">1</a><br class="">
<br class="">
hh<br class="">
<br class="">
<br class="">______________________________<wbr class="">_________________<br class="">
swift-server-dev mailing list<br class="">
<a href="mailto:swift-server-dev@swift.org" target="_blank" class="">swift-server-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-server-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div>
______________________________<wbr class="">_________________<br class="">swift-server-dev mailing list<br class=""><a href="mailto:swift-server-dev@swift.org" target="_blank" class="">swift-server-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-server-<wbr class="">dev</a><br class=""></div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-server-dev mailing list<br class=""><a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></div></blockquote></div><br class=""></div></body></html>