[swift-server-dev] HTTP Parser

[Paulo Faria]

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:

Pros
- Faster to wrap a C lib than to write everything in Swift
- Safer to use a battle-tested C lib
- Better performance when handling strings (major current bottleneck for Swift)

Cons
- We need the OK from Chris Lattner
- If a bug is found we have to either:
  - fix it ourselves and push back upstream
  - if it’s something we don’t know how to fix we report and wait for the fix

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.

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.

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.


> On Nov 3, 2016, at 6:49 PM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> 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.
> 
> 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.
> 
>  - Logan
> 
> On Thu, Nov 3, 2016 at 4:46 PM Tanner Nelson via swift-server-dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> wrote:
> 
> Tanner Nelson
> Vapor 
> +1 (435) 773-2831 <tel:(435)%20773-2831>
>> On Nov 3, 2016, at 4:34 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>> wrote:
>> 
>> On 3 Nov 2016, at 19:41, Alfredo Delli Bovi <alfredo.dellibovi at gmail.com <mailto:alfredo.dellibovi at gmail.com>> wrote:
>>> There has been some discussions about this in Kitura already (https://github.com/IBM-Swift/Kitura-net/issues/52 <https://github.com/IBM-Swift/Kitura-net/issues/52>) and I think we can use what they found out at the moment.
>>> 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.
>> 
>> They claim that their port is just ~1/3 slower, that seems perfectly reasonable to me. I’m all for using it.
> 
> 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. 
> 
> A big performance hit like that is not worth it unless we're getting improved readability or safety out of the code. 
> 
>> 
>> I also agree with the overall sentiment that a ‘pure’ Swift solution should be preferred.
>> 
>>> 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.
>> 
>> Yes, the API should sit on top of this and be essentially parser agnostic.
>> 
>> hh
>> 
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161103/abc860e1/attachment.html>