<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="">Hi, Michael,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>We’re not really talking about the same thing here. </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>This email thread isn’t about an API proposal. It’s about a prototype implementation of an API that was already proposed and discussed a month and a half ago. The prototype isn't a full-featured framework like Vapor or Kitura, but it does actually work and it even has XCTests with decent (>75%) code coverage. </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Also, please note that I didn’t play any part in proposing this API back in March/April - it’s not “Carl’s proposal.” I just took the existing API that the group had previously discussed and implemented enough of it so that we could measure the utility and performance of the API as proposed and so that we could have better informed discussions about potential alternatives. </div><div class=""><br class=""></div><div class="">-Carl</div><br class=""><div><blockquote type="cite" class=""><div class="">On May 27, 2017, at 1:47 AM, Michael Chiu <<a href="mailto:hatsuneyuji@icloud.com" class="">hatsuneyuji@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Carl,<div class=""><br class=""></div><div class="">I feel the same way as you feel. </div><div class=""><br class=""></div><div class="">I have no mean to have everybody start the discussion again :).</div><div class=""><br class=""></div><div class=""> 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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Hi everyone, </div><div class=""><br class=""></div><div class="">Personally, This is how I feel comparing two proposals:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">On Paulo's IO side, Duration sounds real cool to me but that should be the stream-side’s responsibility.</div><div class=""><br class=""></div><div class="">HTTPTransferEncoding is a big plus on Carl’s side.</div><div class=""><br class=""></div><div class="">TL;DR:</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Michael.</div><div class=""><br class=""></div><div class=""> </div><div class=""><blockquote type="cite" class=""><div class="">On May 26, 2017, at 9:21 PM, Carl Brown <<a href="mailto:carl.brown.swift@linuxswift.com" class="">carl.brown.swift@linuxswift.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Hi, Paulo and Michael,</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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 (<a href="https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000329.html" class="">https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000329.html</a>) and going until the discussion died out on Wednesday, April 12th (<a href="https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170410/000450.html" class="">https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170410/000450.html</a>).</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Am I the only one who feels that way?</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">-Carl</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On May 26, 2017, at 8:04 PM, Michael Chiu <<a href="mailto:hatsuneyuji@icloud.com" class="">hatsuneyuji@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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 class=""><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 class="" 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 class=""><span class="" style="font-size: 12.800000190734863px;"><br class=""></span></div><div class=""><span class="" 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 class=""><span class="" style="font-size: 12.800000190734863px;"><br class=""></span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">Week 1</span></div><div class=""><span class="" style="font-size: 12.800000190734863px;"><br class=""></span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">Version</span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">Headers</span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">Message</span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">Request</span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">Response</span></div><div class=""><span class="" style="font-size: 12.800000190734863px;"><br class=""></span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">Week 2</span><span class="" style="font-size: 12.800000190734863px;"><br class=""></span></div><div class=""><span class="" style="font-size: 12.800000190734863px;"><br class=""></span></div><div class=""><span class="" style="font-size: 12.800000190734863px;">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></div></blockquote></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">-- <br class="">Carl Brown, Swift@IBM<br class=""><a href="mailto:Carl.Brown1@IBM.com" class="">Carl.Brown1@IBM.com</a> (Work)<br class="">Austin, TX</div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>