<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><div class="">Hi, Helge,</div><div class=""><br class=""></div><div class=""><div class=""><span style="white-space: pre-wrap;" class="">For purposes of building this prototype, I tried to stay with as many of </span><span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Johannes'</span><span style="white-space: pre-wrap;" class=""> original type signatures as I could. Therefore, </span>I used an enum for <span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">HTTPMethod because that's what </span><span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">Johannes had in his email from </span><span style="white-space: pre-wrap;" class=""><a href="https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170403/000422.html" class="">https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170403/000422.html</a></span></div></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">I'm happy to get into that and other specifics as we go (and yes I added the `RawRepresentable` to the enum because I'm more used to thinking in "200" and "404" than .ok and .notFound, and you are right, a `UInt16` would have been better for status (and maybe I shouldn't have done it at all) - my bad).</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" 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/" class="">https://github.com/swift-server/</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?</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">-Carl</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">-- </span></div><div class=""><span style="white-space: pre-wrap;" class="">Carl Brown, Swift@IBM</span></div><div class=""><span style="white-space: pre-wrap;" class=""><a href="mailto:Carl.Brown1@IBM.com" class="">Carl.Brown1@IBM.com</a> (Work)</span></div><div class=""></div><div class=""><span style="white-space: pre-wrap;" class="">Austin, TX</span></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 26, 2017, at 4:22 PM, Helge Heß 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 class="">On 26. May 2017, at 22:00, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">HTTPRequest: <a href="https://github.com/carlbrown/HTTPSketch/blob/master/Sources/HTTPSketch/HTTPRequest.swift" class="">https://github.com/carlbrown/HTTPSketch/blob/master/Sources/HTTPSketch/HTTPRequest.swift</a> <br class=""></blockquote><br class=""><br class=""> /// HTTP Methods handled by http_parser.[ch] supports<br class=""> public enum HTTPMethod: String {<br class=""> // case custom(method: String)<br class=""> case UNKNOWN<br class=""><br class="">Don’t restrict the API to a specific HTTP parser implementation. The number of methods supported by http_parser changed multiple times in the past (I myself added one to the official tree).<br class=""><br class="">I still highly recommend using constants instead of an enum here. The methods *will* change in the future. (At least BATCH is going to be added)<br class="">At the minimum do the custom(String) variant. UNKNOWN seems unacceptable to me.<br class=""><br class="">In the same run, I don’t understand why an enum is used for methods but not for headers. Extra weird because the method is just a header in HTTP/2 …<br class="">I’d prefer constants for both.<br class=""><br class=""><br class=""><blockquote type="cite" class="">func writeBody(data: DispatchData, completion: @escaping (Result<POSIXError, ()>) -> Void)<br class=""></blockquote><br class="">Do we really want to expose POSIXError’s? I’d say have an own error type for HTTP level errors and maybe something like this:<br class=""><br class=""> enum HTTPError {<br class=""> case connectionClosed(cause: POSIXError?)<br class=""> ...<br class=""> }<br class=""><br class="">Also: DispatchData vs Data vs Ptr.<br class=""><br class=""><br class=""><blockquote type="cite" class="">public enum HTTPResponseStatus: UInt, RawRepresentable {<br class=""> /* The original spec used custom if you want to use a non-standard response code or<br class=""> have it available in a (UInt, String) pair from a higher-level web framework. <br class=""><br class=""> Swift 3 doesn't like it - will revisit in Swift 4*/<br class=""> //case custom(code: UInt, reasonPhrase: String)<br class=""></blockquote><br class="">Swift 3 does like it, you just can’t combine raw w/ extra values. That just doesn’t make sense. I think the only thing you could hope for is that this works on a raw:<br class=""><br class=""> case custom(code: UInt)<br class=""><br class="">Also, why a `UInt`? Do you foresee 64-bit status codes? Should be UInt16.<br class=""><br class=""><br class="">Again: I’d prefer constants because status codes are defined as part of RFCs and<br class="">will *definitely* change in the future. Something like<br class=""><br class=""> struct HTTPStatus {<br class=""> let code : UInt16<br class=""><br class=""> static let `continue` : UInt16 = 100<br class=""> etc.<br class=""> }<br class=""><br class="">That is future and source-compat proof.<br class=""><br class=""><br class=""><blockquote type="cite" class="">public struct HTTPHeaders {<br class=""> var storage: [String:[String]] /* lower cased keys */<br class=""> var original: [(String, String)] /* original casing */<br class=""></blockquote><br class="">I don’t think the storage semantics should be part of the API. I’d prefer<br class="">a protocol here providing indexed access.<br class=""><br class=""><br class="">Finally, I still propose calling it HTTPRequestHead, HTTPResponseHead. The body belongs to the request/response. Don’t care too much, but would be better.<br class=""><br class="">hh<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></body></html>