<div dir="ltr">> <span style="font-size:12.800000190734863px">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><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Week 1</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Version</span></div><div><span style="font-size:12.800000190734863px">Headers</span></div><div><span style="font-size:12.800000190734863px">Message</span></div><div><span style="font-size:12.800000190734863px">Request</span></div><div><span style="font-size:12.800000190734863px">Response</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Week 2</span><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">SyncBody</span></div><div>AsyncBody</div><div><br></div><div>Week 3</div><div><br></div><div>SyncRequestParser</div><div>AsyncRequestParser</div><div>SyncResponseParser</div><div>AsyncResponseParser</div><div><br></div><div>Week 4</div><div><br></div><div>SyncRequestSerializer</div><div>AsyncRequestSerializer</div><div>SyncResponseSerializer</div><div>AsyncResponseSerializer</div><div><br></div><div>Week 5</div><div><br></div><div>SyncServer</div><div>AsyncServer</div><div><br></div><div>Week 6</div><div><br></div><div>SyncClient</div><div>AsyncClient</div><div><br></div><div>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><br></div><div>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><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 May 2017 at 20:40, Carl Brown <span dir="ltr"><<a href="mailto:carl.brown.swift@linuxswift.com" target="_blank">carl.brown.swift@linuxswift.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><span class=""><blockquote type="cite"><div>On May 26, 2017, at 6:07 PM, Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:</div><br class="m_-8462004033862374951Apple-interchange-newline"><div><div dir="ltr">Hi, Carl!<div><br></div><div>I honestly think the code is too overwhelming. </div></div></div></blockquote><div><br></div></span><div>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><blockquote type="cite"><div><div dir="ltr"><div>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><br></div></span><div>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><blockquote type="cite"><div><div dir="ltr"><div>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><br></div></span><div>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><br></div><blockquote type="cite"><div><div dir="ltr"><div>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><br></div></span><div>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"><div><br></div><div>-Carl</div></font></span><span class=""><br><blockquote type="cite"><div><div class="gmail_extra"><div class="gmail_quote">On 26 May 2017 at 19:51, Helge Heß via swift-server-dev <span dir="ltr"><<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Carl,<br>
<span><br>
> 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">https://github.com/swift-serve<wbr>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>
<br>
</span>that seems perfectly reasonable to me.<br>
<br>
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>
<br>
I have Johannes’ original proposal in code over here, in case you need it as a basis:<br>
<br>
<a href="https://github.com/ApacheExpress/ApacheExpress/tree/s3wg-api-proposal-1/S3WGAPIProposal1" rel="noreferrer" target="_blank">https://github.com/ApacheExpre<wbr>ss/ApacheExpress/tree/s3wg-<wbr>api-proposal-1/S3WGAPIProposal<wbr>1</a><br>
<br>
hh<br>
<br>
<br>______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-server-dev</a><br>
<br></blockquote></div><br></div>
______________________________<wbr>_________________<br>swift-server-dev mailing list<br><a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br></div></blockquote></span></div><br></div></blockquote></div><br></div>