<div dir="ltr">Helge! I agree with most of your suggestions and I'll update my proposal with them. There's only one I'm not with you and it's about the HTTP prefix. The example you mentioned could be easily solved by adding `HTTP.` when referring to the specific type.<div><br></div><div><span style="font-size:12.800000190734863px">import HTTP</span></div><div><span style="font-size:12.800000190734863px">import SOAP</span><br style="font-size:12.800000190734863px"><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">let request = HTTP.Request()</span><br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">We have used Request and Response without prefixes for about two years and not once anyone complained about that. I imagine others who use the same naming scheme can testify to that.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">About Sync/Async prefix. I was talking about type prefixes not method prefixes. We definitely shouldn't prefix function APIs with sync or async. I honestly don't care too much about which one to use as a default. I just think it makes more sense to prefix the Async ones.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">About raw buffers we could provide APIs that take an array of </span><span style="font-size:12.800000190734863px">Unsafe[Mutable]RawBufferPointer to pass them to readv, writev and company. Those could also be easily converted to DispatchData in the frameworks that prefer to use it.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 May 2017 at 15:27, Carl Brown 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"><div style="word-wrap:break-word"><div><br></div><div>Hi, Helge,</div><div><br></div><div><div><span style="white-space:pre-wrap">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)">Johannes'</span><span style="white-space:pre-wrap"> 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)">HTTPMethod because that's what </span><span style="white-space:pre-wrap;background-color:rgb(255,255,255)">Johannes had in his email from </span><span style="white-space:pre-wrap"><a href="https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170403/000422.html" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-server-dev/<wbr>Week-of-Mon-20170403/000422.<wbr>html</a></span></div></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">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><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">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/" target="_blank">https://github.com/swift-<wbr>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><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">-Carl</span></div><div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">-- </span></div><div><span style="white-space:pre-wrap">Carl Brown, Swift@IBM</span></div><div><span style="white-space:pre-wrap"><a href="mailto:Carl.Brown1@IBM.com" target="_blank">Carl.Brown1@IBM.com</a> (Work)</span></div><div></div><div><span style="white-space:pre-wrap">Austin, TX</span></div><div><div class="h5"><br><div><blockquote type="cite"><div>On May 26, 2017, at 4:22 PM, Helge Heß 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_-3602182593106417186Apple-interchange-newline"><div><div>On 26. May 2017, at 22:00, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br><blockquote type="cite">HTTPRequest: <a href="https://github.com/carlbrown/HTTPSketch/blob/master/Sources/HTTPSketch/HTTPRequest.swift" target="_blank">https://github.com/<wbr>carlbrown/HTTPSketch/blob/<wbr>master/Sources/HTTPSketch/<wbr>HTTPRequest.swift</a> <br></blockquote><br><br> /// HTTP Methods handled by http_parser.[ch] supports<br> public enum HTTPMethod: String {<br> // case custom(method: String)<br> case UNKNOWN<br><br>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><br>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>At the minimum do the custom(String) variant. UNKNOWN seems unacceptable to me.<br><br>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>I’d prefer constants for both.<br><br><br><blockquote type="cite">func writeBody(data: DispatchData, completion: @escaping (Result<POSIXError, ()>) -> Void)<br></blockquote><br>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><br> enum HTTPError {<br> case connectionClosed(cause: POSIXError?)<br> ...<br> }<br><br>Also: DispatchData vs Data vs Ptr.<br><br><br><blockquote type="cite">public enum HTTPResponseStatus: UInt, RawRepresentable {<br> /* The original spec used custom if you want to use a non-standard response code or<br> have it available in a (UInt, String) pair from a higher-level web framework. <br><br> Swift 3 doesn't like it - will revisit in Swift 4*/<br> //case custom(code: UInt, reasonPhrase: String)<br></blockquote><br>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><br> case custom(code: UInt)<br><br>Also, why a `UInt`? Do you foresee 64-bit status codes? Should be UInt16.<br><br><br>Again: I’d prefer constants because status codes are defined as part of RFCs and<br>will *definitely* change in the future. Something like<br><br> struct HTTPStatus {<br> let code : UInt16<br><br> static let `continue` : UInt16 = 100<br> etc.<br> }<br><br>That is future and source-compat proof.<br><br><br><blockquote type="cite">public struct HTTPHeaders {<br> var storage: [String:[String]] /* lower cased keys */<br> var original: [(String, String)] /* original casing */<br></blockquote><br>I don’t think the storage semantics should be part of the API. I’d prefer<br>a protocol here providing indexed access.<br><br><br>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><br>hh<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" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br></div></div></blockquote></div><br></div></div></div><br>______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org">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/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
<br></blockquote></div><br></div>