[swift-server-dev] HTTP Parser

[Logan Wright]

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.

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.

- Logan

On Thu, Nov 3, 2016 at 2:41 PM Alfredo Delli Bovi <
alfredo.dellibovi at gmail.com> wrote:

> Hi people,
>
> There has been some discussions about this in Kitura already (
> 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.
>
> 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.
>
> —
> Alfredo Delli Bovi
>
> On 3 Nov 2016, at 19:35, Logan Wright via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
> 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.
>
> 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.
>
> - Logan
>
> On Thu, Nov 3, 2016 at 1:27 PM Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
> Hi Logan,
>
> On 03 Nov 2016, at 17:50, Logan Wright <logan at qutheory.io> wrote:
> > Yup, you can see a lot of it in the underlying engine module from Vapor.
>
> is it this one?:
>
>
> https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift
>
> that seems to be a pull based / blocking parser, right? That probably
> doesn’t work for a lot of environments.
>
>
> Personally I’d suggest a small wrapper around this one:
>
>   https://github.com/nodejs/http-parser
>
> It is small, fast, highly efficient, zero copy, push based, supports
> chunked&upgrade and is extremely well tested and widely deployed.
>
>
> 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):
>
>   https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser
>
> My approach here was to keep it close to the original, which makes for
> really ugly code :-)
> 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 :-).
>
>
> 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`? :-)
>
>
> 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.
> Why important? Well, because there needs to be a way to pass the data
> between those components w/o copying it :-)
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> 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/fea0e616/attachment.html>