<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="">Completely agree.<div class="">Also, a poor performance at that stage of the request could lead to security issues too: i.e. DDoS attacks would be easier to execute.<br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><table cellspacing="0" cellpadding="0" style="background-color: rgb(255, 255, 255); padding: 0px; margin: 0px; font-family: 'Lucida Grande', sans-serif; font-size: 12px; color: rgb(176, 176, 176);" class=""><tbody class=""><tr style="margin: 0px; padding: 0px;" class=""><td style="font-family: arial, sans-serif; margin: 0px; padding: 0px; white-space: nowrap;" class=""><span style="color: rgb(73, 79, 80); font-family: 'Helvetica Neue', san-serif; font-size: 14px; white-space: normal;" class="">—<br class=""></span><span style="color: rgb(0, 0, 0); font-family: Helvetica; white-space: normal;" class="">Alfredo Delli Bovi</span></td></tr></tbody></table></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 4 Nov 2016, at 09:50, Samuel Kallner 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="">I agree with Paulo. One of Swift's strong
points is its ability to bind with all sorts of existing "system"
C based APIs. Especially C APIs that are extremely well tested and maintained.
We should all remember that while many of us may have taken the http_parser
from Node, Node itself took it from Nginx. This code comes with great pedigree.</font><br class=""><br class=""><font size="2" face="sans-serif" class="">Why should we spend time developing
an HTTP parser in Swift when we should be spending our collective time
higher up the Web Server Framework toolchain? </font><font size="3" class="">Alfredo
Delli Bovi</font><font size="2" face="sans-serif" class=""> quoted the work that was
done Dave Sperling to port the HTTP Parser Kitura was using to Swift. While
he ported the code, he did not write the complete Unit Test Suite needed
for that code. His own estimate was that writing the tests would be approximately
two to three times the effort of the original port. I also seem to remember
that the performance hit for that particular code was more than 33%.</font><br class=""><br class=""><font size="2" face="sans-serif" class="">Another point, which is especially true
on current Swift drivers, is that any code that is going to parse something
like HTTP requests and responses is probably going to have to work at the
byte level and not that String level. This is due to performance issues.
At the byte level its actually a lot easier to write C code, than Swift
code. This may change in the future, but lets wait until this kind of thing
gets more performant in Swift.</font><br class=""><br class=""><font size="2" face="sans-serif" class="">Some have said that readability is more
important than performance. I for one, who have read the http_parser code
from time to time, find rather readable for a tightly written finite state
machine. Here I also beg to disagree that performance isn't important.
In a server one wants to spend cycles doing real work for the requestor,
not figuring out what he wants you to do. To scale one needs to be performant.</font><br class=""><br class=""><font size="2" face="sans-serif" class="">Shmuel Kallner</font><br class=""><font size="2" face="sans-serif" class="">STSM Smart Client Platforms group<br class="">Tel: +972-4829-6430<br class="">e-mail: <a href="mailto:kallner@il.ibm.com" class="">kallner@il.ibm.com</a></font><br class=""><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="">Paulo Faria 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="">Logan Wright <<a href="mailto:logan@qutheory.io" class="">logan@qutheory.io</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="">04/11/2016 00:15</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 think wrapping a battle-tested C library is the way
to go. Using a C library is not the same as writing one. In our case we’ll
have to deal with C APIs anyway (POSIX), so the experience won’t be something
we’re not used to already. Pragmatically here are the pros and cons:</font><br class=""><br class=""><font size="3" class="">Pros</font><br class=""><font size="3" class="">- Faster to wrap a C lib than to write everything in Swift</font><br class=""><font size="3" class="">- Safer to use a battle-tested C lib</font><br class=""><font size="3" class="">- Better performance when handling strings (major current
bottleneck for Swift)</font><br class=""><br class=""><font size="3" class="">Cons</font><br class=""><font size="3" class="">- We need the OK from Chris Lattner</font><br class=""><font size="3" class="">- If a bug is found we have to either:</font><br class=""><font size="3" class=""> - fix it ourselves and push back upstream</font><br class=""><font size="3" class=""> - if it’s something we don’t know how to fix
we report and wait for the fix</font><br class=""><br class=""><font size="3" class="">I’ve been using http_parser on Zewo for over an year
and I haven’t found a single bug yet. That’s *very* unlikely to happen
if we write a Swift parser ourselves.</font><br class=""><br class=""><font size="3" class="">About the binary data discussion. I think something so
important like that should reside in the standard library. I don’t think
a protocol is a good idea because it promotes the creation of even more
binary abstractions which is no good. I know the proposal of a new “data”
type on the standard library falls on what I just said, *but* in a perfect
world Foundation would lose NSData in favor of the standard library Data
pretty much like it did for NSString/String. Eventually all other frameworks
would be using standard library’s Data too.</font><br class=""><br class=""><font size="3" class="">The feeling I got from Ted Kremenek is that we should
picture the best scenario and then see where our work might land. This
is the perfect case for that.</font><br class=""><br class=""><br class=""><font size="3" class="">On Nov 3, 2016, at 6:49 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:</font><br class=""><br class=""><font size="3" class="">Following up with what Tanner and Chris said. I think
HTTP 2 is particularly difficult, and you're right chris, bringing in a
c library, even if just temporarily will help expedite the process in an
efficient way.</font><br class=""><br class=""><font size="3" class="">I am however pretty ardently against porting C code to
Swift as opposed to rethinking things for a Swift paradigm. If that's the
case, I'd prefer to either link to the c code, or bring it into the Swift
compiler. The end result would appear to be the same.</font><br class=""><br class=""><font size="3" class=""> - Logan</font><br class=""><br class=""><font size="3" class="">On Thu, Nov 3, 2016 at 4:46 PM Tanner Nelson 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" color="#5f5f5f" class="">Tanner Nelson</font><br class=""><font size="3" color="#9f9fe0" class="">Va</font><font size="3" color="#b1b1d2" class="">p</font><font size="3" color="#c0c0c0" class="">o</font><font size="3" color="#bfbfbf" class="">r</font><font size="3" color="#9f9fe0" class=""></font><br class=""><a href="tel:(435)%20773-2831" target="_blank" class=""><font size="3" color="blue" class=""><u class="">+1
(435) 773-2831</u></font></a><br class=""><br class=""><font size="3" class="">On Nov 3, 2016, at 4:34 PM, Helge Heß via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org" target="_blank" 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 3 Nov 2016, at 19:41, Alfredo Delli Bovi <</font><a href="mailto:alfredo.dellibovi@gmail.com" target="_blank" class=""><font size="3" color="blue" class=""><u class="">alfredo.dellibovi@gmail.com</u></font></a><font size="3" class="">>
wrote:</font><br class=""><font size="3" class="">There has been some discussions about this in Kitura already
(</font><a href="https://github.com/IBM-Swift/Kitura-net/issues/52" target="_blank" class=""><font size="3" color="blue" class=""><u class="">https://github.com/IBM-Swift/Kitura-net/issues/52</u></font></a><font size="3" class="">)
and I think we can use what they found out at the moment.<br class="">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 class=""><font size="3" class=""><br class="">They claim that their port is just ~1/3 slower, that seems perfectly reasonable
to me. I’m all for using it.</font><br class=""><br class=""><font size="3" class="">As far as I can tell, the package in question here is
a carbon copy of the C parser (UnsafePointers, asserts, global funcs).
The only difference is it's 1/3 slower. </font><br class=""><br class=""><font size="3" class="">A big performance hit like that is not worth it unless
we're getting improved readability or safety out of the code. </font><br class=""><br class=""><font size="3" class=""><br class="">I also agree with the overall sentiment that a ‘pure’ Swift solution
should be preferred.<br class=""></font><br class=""><font size="3" class="">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 class=""><font size="3" class=""><br class="">Yes, the API should sit on top of this and be essentially parser agnostic.<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" target="_blank" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target="_blank" class=""><font size="3" color="blue" class=""><u class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></a><br class=""><br class=""><font size="3" 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" target="_blank" class=""><font size="3" color="blue" class=""><u class="">swift-server-dev@swift.org</u></font></a><font size="3" color="blue" class=""><u class=""><br class=""></u></font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" target="_blank" class=""><font size="3" color="blue" class=""><u class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</u></font></a><br class=""><font size="3" 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="">_______________________________________________<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></body></html>