<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 everyone,</div><div class=""><br class=""></div><div class="">Just wanted to add a couple of thoughts to the conversation.</div><div class=""><br class=""></div><div class="">We have set this ambitions deadline in mind for the first version of the API’s and, with that in sight, it is highly unlikely that we’ll be able to write a parser in Swift. Also it is a monumental task to rewrite the whole thing - with all it’s specs, edge cases, support for v1.1, v2, byte-ranges, pipelining, multipart requests, a.s.o. - I know. I’ve done it. It sucks.</div><div class=""><br class=""></div><div class="">That being said, I cannot ignore the opportunity that we have at this point. Developing a parser from scratch, while working along side people that develop Foundation would allow us to also improve the language at the same time. Is there need for something similar to pointer arithmetic? Let’s make it. Does Foundation make too many data copy ops? Let’s make it so that it doesn’t. Is dispatch missing a kernel space component so that it can come close to Darwin in terms of speed? Let’s get that done as well. </div><div class=""><br class=""></div><div class="">All in all, I think that it’s worth looking more towards the long term benefits, rather the somewhat immediate result of having it “now”. After all it’s not like we have to *convince* the swift community to adopt it. The need is already there. Also, since everyone has already, to a larger or lesser extent, wrapped node’s parser around swift API’s, what’s the point of doing that again? Just to be able to say that this implementation “comes with swift”? I don’t believe it’s worth it. Again, this is just personal preference; I guess, I believe in doing things once, and not coming back to them over and over again. I digress. </div><div class=""><br class=""></div><div class="">As as I said in the begging, I do understand the time constraints and the inherent value that comes with using a tried and tested solution thus allowing us to focus on the design of the developer facing APIs. All in all, I agree with Chris that the first thing should be to spec out what an “ideal world” version would contain, without all the constraints we have.</div><div class=""><br class=""></div><div class="">Apologies for the rant,</div><div class=""><br class=""></div><div class="">Catalin</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Nov 2016, at 02.59, Chris Bailey 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=""><font size="2" face="sans-serif" class="">To add some data into the debate...</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">The C based http_parser used by Node.js
(and original from NGINX) is approx 3K lines of code. If we think strictly
in terms of effort to implement (and ignore maintenance costs or what's
required to reach the same quality levels etc) then it shouldn't be an
unreasonable amount of effort to do a Swift implementation - and in fact
we could look at both approaches and see which is preferable (as both approaches
have been taken by Swift frameworks already).</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">The nghttp2 library however is approx
64K lines of code (looking only at the src directory). As such, its a much
bigger task to implement, and to do so in a bug-free manner - note that
the tests are another 17K lines of code.</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">As an aside, wrapping the nghttp2 library
is the approach being taken by Node.js for their HTTP/2 support.</font>
<br class="">
<br class=""><font size="2" face="sans-serif" class="">Chris<br class="">
</font>
<br class="">
<br class="">
<br class="">
<br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">From:
</font><font size="1" face="sans-serif" class="">Tyler Cloutier via
swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>></font>
<br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">To:
</font><font size="1" face="sans-serif" class="">Helge Heß <<a href="mailto:me@helgehess.eu" class="">me@helgehess.eu</a>></font>
<br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Cc:
</font><font size="1" face="sans-serif" class="">Swift Server Dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>></font>
<br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Date:
</font><font size="1" face="sans-serif" class="">06/11/2016 19:35</font>
<br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Subject:
</font><font size="1" face="sans-serif" class="">Re: [swift-server-dev]
HTTP Parser</font>
<br class=""><font size="1" color="#5f5f5f" face="sans-serif" class="">Sent by:
</font><font size="1" face="sans-serif" class=""><a href="mailto:swift-server-dev-bounces@swift.org" class="">swift-server-dev-bounces@swift.org</a></font>
<br class="">
<hr noshade="" class="">
<br class="">
<br class="">
<br class=""><font size="3" class="">I would agree that wrapping the nodejs http_parser is
probably the way to go for now. There is a lot of places we could spend
our time, but given that that is an extremely well tested program at this
point, I don’t see the need to put any wood behind that arrow. Writing
a Swift wrapper around it is not difficult and frees us up to work on other
more pressing things. In fact many of us, have already </font><a href="https://github.com/SwiftOnEdge/Edge/blob/master/Sources/HTTP/Parser.swift" class=""><font size="3" color="blue" class=""><u class="">done
it</u></font></a><font size="3" class="">.</font>
<br class="">
<br class="">
<br class=""><font size="3" class="">Tyler</font>
<br class="">
<br class="">
<br class=""><font size="3" class="">On Nov 4, 2016, at 2:18 PM, Helge Heß via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" class="">>
wrote:</font>
<br class="">
<br class=""><font size="3" class="">On 4 Nov 2016, at 21:20, Paulo Faria <</font><a href="mailto:paulo@zewo.io" class=""><font size="3" color="blue" class=""><u class="">paulo@zewo.io</u></font></a><font size="3" class="">>
wrote:</font>
<br class=""><font size="3" class="">Logan, would you be kind to explain why you think we shouldn’t
touch C?</font>
<br class=""><font size="3" class=""><br class="">
Well, I think the rational is pretty clear. Staying within a single language
has obvious benefits. Add to that safety features inherent to Swift designed
solutions (buffer overruns and such) as well as the relative beauty of
a modern language.<br class="">
<br class="">
http_parser is a very C thing, it makes extensive use of pointers, goto’s
and other C ‘tricks' to accomplish the performance it has. It is reasonably
small and focused code but certainly not code which is straight forward
to read&understand.<br class="">
<br class="">
At the same time http_parser is a nice demo on how a high performance C
core implementation is used in a high-level language environment (Node.js).
The user of Node.js doesn’t have to deal with the C stuff at all.<br class="">
<br class="">
Anyways I stick to my original opinion:<br class="">
—snip---<br class="">
Personally I’d suggest a small wrapper around this one: </font><a href="https://github.com/nodejs/http-parser" class=""><font size="3" color="blue" class=""><u class="">https://github.com/nodejs/http-parser</u></font></a><font size="3" class=""><br class="">
—snap—<br class="">
<br class="">
But if someone has a great Swift parser providing the key features I’m
interested in (push based, as zero copy as possible, reasonably fast),
I’m quite interested too :-><br class="">
<br class="">
hh<br class="">
<br class="">
</font>
<br class=""><font size="3" class="">My argument is that using a C library that we all know
works well gives us time to work on more important things, like the user-facing
API. You mentioned that we all like Swift because it’s safe, succinct
and clean. I think we can all agree with that, but that statement doesn’t
correlate to using a C lib. We wouldn’t be _implementing_ the parser in
c, we would be _using_ a existing c parser. So the work would fall into
what we’ll already have to do when dealing with C POSIX APIs, for example.
Using a C lib would be one less thing to maintain. So again we can focus
on creating safe, succinct and clean code where it really matters, the
API level.<br class="">
<br class="">
</font>
<br class=""><font size="3" class="">On Nov 4, 2016, at 5:18 PM, Logan Wright via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" class="">>
wrote:<br class="">
<br class="">
Helge, if I had my way, we wouldn't touch C in any way whatsoever for any
of the server side libraries except as an absolute last resort, but this
life is full of compromise, and I'm trying to be amicable to come up with
solutions that we can agree on.<br class="">
<br class="">
For HTTP2 as well, I'd like plans to eventually move to pure swift native
implementations rethought for the language. <br class="">
<br class="">
On Fri, Nov 4, 2016 at 3:17 PM Helge Heß via swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" class="">>
wrote:<br class="">
On 4 Nov 2016, at 20:11, Logan Wright via swift-server-dev <</font><a href="mailto:swift-server-dev@swift.org" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" class="">>
wrote:</font>
<br class=""><font size="3" class="">That said, even if we do end up doing that short term,
I'd like to include plans or at least intentions to do things in Swift.
I (and I'm sure many of us) generally prefer working in Swift because it's
safe, succinct, and clean. We also have several instances of existing HTTP
parsers we could pull from, it's not like we're starting from 0 as a group.<br class="">
<br class="">
For HTTP2, I think everyone is in agreement that a c library is the way
to go. I'd like to give HTTP a bit more time for opinions to come in.</font>
<br class=""><font size="3" class=""><br class="">
I’m not entirely sure why you have double standards here. Why would you
come up with a safe, succinct and clean HTTP/1.x parser but not do the
same for HTTP/2?<br class="">
<br class="">
hh<br class="">
<br class="">
_______________________________________________<br class="">
swift-server-dev mailing list</font><font size="3" color="blue" class=""><u class=""><br class="">
</u></font><a href="mailto:swift-server-dev@swift.org" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" class=""><br class="">
</font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class=""><font size="3" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></a><font size="3" 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="">
</font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class=""><font size="3" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></a>
<br class="">
<br class=""><font size="3" class=""><br class="">
_______________________________________________<br class="">
swift-server-dev mailing list</font><font size="3" color="blue" class=""><u class=""><br class="">
</u></font><a href="mailto:swift-server-dev@swift.org" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" class=""><br class="">
</font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class=""><font size="3" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></a>
<br class=""><tt class=""><font size="2" 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="">
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class=""><tt class=""><font size="2" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt class=""><font size="2" class=""><br class="">
</font></tt>
<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></blockquote></div><br class=""></body></html>