<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="">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:</div><div class=""><br class=""></div><div class="">Pros</div><div class="">- Faster to wrap a C lib than to write everything in Swift</div><div class="">- Safer to use a battle-tested C lib</div><div class="">- Better performance when handling strings (major current bottleneck for Swift)</div><div class=""><br class=""></div><div class="">Cons</div><div class="">- We need the OK from Chris Lattner</div><div class="">- If a bug is found we have to either:</div><div class=""> - fix it ourselves and push back upstream</div><div class=""> - if it’s something we don’t know how to fix we report and wait for the fix</div><div class=""><br class=""></div><div 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.</div><div class=""><br class=""></div><div 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.</div><div class=""><br class=""></div><div 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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Nov 3, 2016, at 6:49 PM, 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="">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.<div class=""><br class=""></div><div 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.</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 4:46 PM Tanner Nelson 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"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class="gmail_msg"><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class="gmail_msg"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class="gmail_msg"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class="gmail_msg"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word" class="gmail_msg"><div style="font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><div class="gmail_msg"><font color="#5f5f5f" class="gmail_msg">Tanner Nelson</font></div><div style="" class="gmail_msg"><font color="#9dacd1" class="gmail_msg">Va</font><font color="#aeb2cf" class="gmail_msg">p</font><font color="#c8bacd" class="gmail_msg">o</font><font color="#d0becc" class="gmail_msg">r</font><font color="#9dacd1" class="gmail_msg"> </font></div><div class="gmail_msg"><font color="#676767" class="gmail_msg"><a href="tel:(435)%20773-2831" value="+14357732831" class="gmail_msg" target="_blank">+1 (435) 773-2831</a></font></div></div></div></div></div></div></div>
</div>
<br class="gmail_msg"></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Nov 3, 2016, at 4:34 PM, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:</div><br class="m_968360504658850123Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On 3 Nov 2016, at 19:41, Alfredo Delli Bovi <<a href="mailto:alfredo.dellibovi@gmail.com" class="gmail_msg" target="_blank">alfredo.dellibovi@gmail.com</a>> wrote:<br class="gmail_msg"><blockquote type="cite" class="gmail_msg">There has been some discussions about this in Kitura already (<a href="https://github.com/IBM-Swift/Kitura-net/issues/52" class="gmail_msg" target="_blank">https://github.com/IBM-Swift/Kitura-net/issues/52</a>) and I think we can use what they found out at the moment.<br class="gmail_msg">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.<br class="gmail_msg"></blockquote><br class="gmail_msg">They claim that their port is just ~1/3 slower, that seems perfectly reasonable to me. I’m all for using it.<br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">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. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">A big performance hit like that is not worth it unless we're getting improved readability or safety out of the code. </div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">I also agree with the overall sentiment that a ‘pure’ Swift solution should be preferred.<br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">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.<br class="gmail_msg"></blockquote><br class="gmail_msg">Yes, the API should sit on top of this and be essentially parser agnostic.<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" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg"></div></div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<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=""></body></html>