Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!

Subject: Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-10-04 19:56:55

On Wed, Oct 4, 2017 at 9:44 AM, Vinícius dos Santos Oliveira
<vini.ipsmaker_at_[hidden]> wrote:
> Could you compare this to my parser[1]?

HTTP parsing is a pretty well defined problem and if you
want to have decent performance, there aren't a whole
lot of different ways to write it. Looking over your code
I don't see any obvious implementation mistakes although
as far as the interface goes I would have made different
choices, as you can see by looking at the declaration:

<https://github.com/boostorg/beast/blob/7fe74b1bf544a64ecf8985fde44abf88f9902251/include/boost/beast/http/basic_parser.hpp#L171>

The biggest, obvious difference is that beast::http::basic_parser
and beast::http::serializer are already in Boost, and have gotten
extensive testing and vetting from stakeholders. It is also
running on production servers that handle hundreds of
millions of dollars worth of financial transactions per month.

> It could be that I'm slow

I don't know if I would say that you're slow as I have not
observed your workflow but a comparison is probably unfair,
as I have the opportunity to work on Beast and related projects
such as Boost.Buffers and Boost.HTTPKit full-time.

> but I'm starting to think you like to rush design decisions.

Now that is really unfair, and ignores the enormous amount
of hours not just from me but from all of the other people
who participated in the design of Beast (note that I invited
you to be one of those participants).

Nothing about Beast was rushed, in fact for 3 months in
2016 I was blocked on the parser design because I could
not figure out an elegant interface that worked with the
stream algorithms and allowed the users to supply their
own buffer for the body. I tried several different designs,
if you look in the commit log you can find those alternate
designs.

Here are just a few of the design collaborations that helped
to get Boost.Beast where it is at today:

    Progressive body reading (122 comments!)
    <https://github.com/boostorg/beast/issues/154>

    Split parsing / headers first
    <https://github.com/boostorg/beast/issues/132>

    Expect: 100-continue design
    <https://github.com/boostorg/beast/issues/123>

    Message container constructors
    <https://github.com/boostorg/beast/issues/13>

    Fields concept and allocator support
    <https://github.com/boostorg/beast/issues/124>

    Refactor Body types
    <https://github.com/boostorg/beast/issues/580>

    Asio deallocate-before-invoke contract
    <https://github.com/boostorg/beast/issues/215>

And this does not include over a hundred hours working
with engineers from Ripple (Beast was originally designed
for them) on shared code pads to create the initial container
and stream algorithm ideas.

Quite a lot of time went into the design of Beast in fact there
was far more time spent designing than actual coding. And
I couldn't have done it without the very helpful interaction with
actual users of the library; Beast was shaped by the needs of
stakeholders.

As a reminder to everyone, the Beast pull request / issues
queue is open to all and I welcome anyone who wants to
participate in the design of the library to jump right in and
comment on any of the issues or pull requests. You can see
that there are a number of open issues that have unresolved
design questions:

<https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aopen+label%3ADesign>

Thanks!