<font size=2 face="sans-serif">I think one thing that needs to be considered
is HTTP/2 support - implementing HTTP/2 is significantly more complex that
HTTP 1.x, so if we want to support HTTP/2 it may make more sense to look
at what we can reuse (the nghttp2 library?)</font>
<br>
<br><font size=2 face="sans-serif">Chris </font>
<br>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Tanner Nelson via swift-server-dev
<swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Logan Wright <logan@qutheory.io></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">Swift Server Dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">03/11/2016 18:51</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
HTTP Parser</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">swift-server-dev-bounces@swift.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>I think it's important to remember that performance is
not the only concern.</font>
<br>
<br><font size=3>If we need to use the node_http parser because of time
constraints, I'd prefer that over creating a non-Swifty copy. If you want
the functionality of UnsafePointers, C is the better language to be working
in.</font>
<br>
<br><font size=3>Going forward I think a Swifty HTTP parser could get decent
performance. More importantly though it would be incredibly concise, readable,
and maintainable.</font>
<br>
<br><font size=3 color=#5f5f5f>Tanner Nelson</font>
<br><font size=3 color=#9f9fe0>Va</font><font size=3 color=#b1b1d2>p</font><font size=3 color=#c0c0c0>o</font><font size=3 color=#bfbfbf>r</font><font size=3 color=#9f9fe0>
</font>
<br><font size=3 color=#5f5f5f>+1 (435) 773-2831</font>
<br>
<br><font size=3>On Nov 3, 2016, at 2:42 PM, Logan Wright via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br>
<br><font size=3>Completely agree Alex, I also feel strongly about the
language in general, and I think if we're going to take the time to build
out Swift server apis, they should be in well, Swift.</font>
<br>
<br><font size=3>In terms of performance, Swift will only continue to improve
in performance, and given our access to the compiler team and the smart
minds in this room. I think we can beat the node parser with time.<br>
<br>
- Logan</font>
<br>
<br><font size=3>On Thu, Nov 3, 2016 at 2:41 PM Alfredo Delli Bovi <</font><a href=mailto:alfredo.dellibovi@gmail.com><font size=3 color=blue><u>alfredo.dellibovi@gmail.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>Hi people,</font>
<br>
<br><font size=3>There has been some discussions about this in Kitura already
(</font><a href="https://github.com/IBM-Swift/Kitura-net/issues/52" target=_blank><font size=3 color=blue><u>https://github.com/IBM-Swift/Kitura-net/issues/52</u></font></a><font size=3>)
and I think we can use what they found out at the moment.</font>
<br><font size=3>In my opinion, if we are not able to give the same (or
better) performance we should go for a wrapper of a more performant lib,
such as http_parser.</font>
<br>
<br><font size=3>Of course it’s also matter of the workload that have,
we could always start with a wrapper, so we are able to define the APIs
layer and ship a version with it and later on changing the implementation
with a pure Swift.</font>
<br>
<table width=13 style="border-collapse:collapse;">
<tr height=8>
<td width=13 bgcolor=white style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=2 color=#4f4f4f face="Helvetica Neue">—</font></table>
<br>
<table width=88 style="border-collapse:collapse;">
<tr height=8>
<td width=88 bgcolor=white style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=1 color=#b2b2b2 face="Helvetica">Alfredo
Delli Bovi</font><font size=2 color=#4f4f4f face="Helvetica Neue"> </font></table>
<br>
<br><font size=3>On 3 Nov 2016, at 19:35, Logan Wright via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br>
<br><font size=3>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.</font>
<br>
<br><font size=3>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.</font>
<br>
<br><font size=3>- Logan</font>
<br>
<br><font size=3>On Thu, Nov 3, 2016 at 1:27 PM Helge Heß via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br><font size=3>Hi Logan,<br>
<br>
On 03 Nov 2016, at 17:50, Logan Wright <</font><a href=mailto:logan@qutheory.io target=_blank><font size=3 color=blue><u>logan@qutheory.io</u></font></a><font size=3>>
wrote:<br>
> Yup, you can see a lot of it in the underlying engine module from
Vapor.<br>
<br>
is it this one?:<br>
<br>
</font><a href=https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift target=_blank><font size=3 color=blue><u>https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift</u></font></a><font size=3><br>
<br>
that seems to be a pull based / blocking parser, right? That probably doesn’t
work for a lot of environments.<br>
<br>
<br>
Personally I’d suggest a small wrapper around this one:<br>
<br>
</font><a href="https://github.com/nodejs/http-parser" target=_blank><font size=3 color=blue><u>https://github.com/nodejs/http-parser</u></font></a><font size=3><br>
<br>
It is small, fast, highly efficient, zero copy, push based, supports chunked&upgrade
and is extremely well tested and widely deployed.<br>
<br>
<br>
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>
<br>
</font><a href=https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser target=_blank><font size=3 color=blue><u>https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser</u></font></a><font size=3><br>
<br>
My approach here was to keep it close to the original, which makes for
really ugly code :-)<br>
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>
<br>
<br>
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>
<br>
<br>
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>
Why important? Well, because there needs to be a way to pass the data between
those components w/o copying it :-)<br>
<br>
hh<br>
<br>
_______________________________________________<br>
swift-server-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target=_blank><font size=3 color=blue><u>https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></a>
<br><font size=3>_______________________________________________<br>
swift-server-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:swift-server-dev@swift.org" target=_blank><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target=_blank><font size=3 color=blue><u>https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></a>
<br>
<br><font size=3>_______________________________________________<br>
swift-server-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3><br>
</font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><font size=3>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></a>
<br><tt><font size=2>_______________________________________________<br>
swift-server-dev mailing list<br>
swift-server-dev@swift.org<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>