<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="">One advantage of a 'pure Swift' approach (as opposed to delegating out to an existing C library) is that it will avoid some of the third party dependency concerns which may prevent dependencies on third parties being added to the Swift project.<div class=""><br class=""></div><div class="">Alex<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Nov 2016, at 11:35, Logan Wright 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="">Helge, definitely depends on the underlying network/dispatch scheme that we go with. I doubt we'd pull in my original code 1:1. But it does speak to my experience w/ the RFC spec in particular.<div class=""><br class=""></div><div class="">I'd personally opt for pure-swift over c-wrapper. I think it will be easier to maintain/deploy/optimize going forward. I don't have an inherent problem w/ the nodejs parser aside from that if people strongly prefer to use c-code here.</div><div class=""><br class=""></div><div class="">- Logan</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 3, 2016 at 1:27 PM Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Logan,<br class="gmail_msg">
<br class="gmail_msg">
On 03 Nov 2016, at 17:50, Logan Wright <<a href="mailto:logan@qutheory.io" class="gmail_msg" target="_blank">logan@qutheory.io</a>> wrote:<br class="gmail_msg">
> Yup, you can see a lot of it in the underlying engine module from Vapor.<br class="gmail_msg">
<br class="gmail_msg">
is it this one?:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift</a><br class="gmail_msg">
<br class="gmail_msg">
that seems to be a pull based / blocking parser, right? That probably doesn’t work for a lot of environments.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Personally I’d suggest a small wrapper around this one:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/nodejs/http-parser" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/nodejs/http-parser</a><br class="gmail_msg">
<br class="gmail_msg">
It is small, fast, highly efficient, zero copy, push based, supports chunked&upgrade and is extremely well tested and widely deployed.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
I also did a straight port of that to Swift, though if you can use the C version I wouldn't use the port as it is significantly slower (and may have extra bugs introduced during the port):<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser</a><br class="gmail_msg">
<br class="gmail_msg">
My approach here was to keep it close to the original, which makes for really ugly code :-)<br class="gmail_msg">
I think it may be worthwhile to do another attempt of a port of the parser, but less 1:1 like mine, in a Swiftier way (the original uses a lot of goto’s :-).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
As mentioned, I wouldn’t expect people to use the low level API but rather have nice objects filled by the underlying parser. What about `WORequest` & `WOResponse`? :-)<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
BTW: Something I consider important to discuss across all areas of interest (crypto, sockets, HTTP) is a protocol to represent a chunks of bytes and chunks of chunks of bytes (buckets and brigades in Apache terms). Of course that could be just NSData or DispatchData but I expect that some frameworks have their own way to represent such buffers, hence a protocol would be nice.<br class="gmail_msg">
Why important? Well, because there needs to be a way to pass the data between those components w/o copying it :-)<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
</blockquote></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></div></body></html>