Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-03 00:00:21

On 02/07/2017 18:25, Vinnie Falco wrote:
> On Sun, Jul 2, 2017 at 9:07 AM, Niall Douglas via Boost
> <boost_at_[hidden]> wrote:
>> Ok, Vinnie. Enough of the aggression.
>> ...
>> If you don't want my feedback because of some grudge against me, say so
>
> There's no grudge but this is what I'm hearing:
>
>    "Beast should not perform socket I/O."
>
> I don't know if its your style of speaking, or word choice but this
> feedback is patently absurd on the face of it.

I don't see the absurdity at all.

Let me give you some background.

I've implemented basic HTTP perhaps six times now in my career to date.
Four times in C/C++, twice in Python. I don't have the depth of
knowledge of full fat HTTP like say Bjorn does, seeing as he contributed
extensively to curl, but I've implemented this stuff lots of times now.

And how you've designed Beast is close to my earlier HTTP
implementations, and far from my later HTTP implementations. This is why
I keep asking about your fundamental design assumptions. I think you
evolved your design starting from the assumption of socket i/o, when you
should have started from blobs of structured data in, blobs of
structured data out. I know for a fact that's suboptimal because I've
been there before too.

> So you think users
> shouldn't be able to implement a web server or HTTP client using
> Beast? How does one even begin to respond to that?

Your userbase to date suffers from selection bias. They want something
which works with ASIO, so they use Beast because it ticks that box. I
can assure you that for every user you have gained to date, you lost at
least two, maybe three users who looked at that ASIO dependency and
thought "god no, not worth the hassle" because they also know how
painful it is to get a custom socket implementation to work with ASIO.

I also know that you'll never, ever encompass all the weird data
transports your full potential user base will have. All sorts of weird
custom, often proprietary things. So free your library of the ASIO
dependency. You don't need it, indeed it's damaging you. Design your
library to work with any unknown transport instead. For example,
switched banks of reference counted shared memory with the current one
selected by a std::atomic<char *>. Blobs of structured data in, blobs of
structured data out - that's your only requirement.

As I've mentioned on list now several times, ASIO readily will consume
any custom gather buffer sequence type: simply specialise the
appropriate ASIO free functions and traits and you can feed it
beast::const_raw_buffer which is a const char * and a size_t (or still
better, a span<const char> or a string_view). So your library's users
can #include <boost/beast/asio_buffer_adapters.hpp> or something and
thereafter directly feed Beast scatter-gather buffer sequences to ASIO.
Or they can for loop them into an array of struct iovec and call the
equivalent of writev() on whatever weird custom transport they are using.

Point is, you need to be _facilitating_ i/o, not _implementing_ i/o.

> I'm going to push
> back considerably on statements of the form "your library shouldn't do
> what it does" such as yours.

I think your library should focus on making HTTP easy for everybody with
a need for HTTP. Do one thing really well, it's where Boost.Http fell down.

> I want to give you the benefit of the doubt, maybe you're trying to
> say something else such as, the library should be presented as two
> separate libraries? But that's not how it sounds.

BTW, just so you know, I'm currently on a conditional accept with a low
confidence interval. It's why I'm interrogating your fundamental design
choices: as much as the _correct_ HTTP library design allows things like
switched banks of shared memory as the transport, such flexibility is
not _necessary_ for a HTTP implementation. And where I am stuck is on
what weighting to give these imperatives, you must remember it's not
just you and me going back and forth. Lots of other people are likely as
stuck on this as me and are reading everything on boost-dev. So your
justifications of design choice to me, and persuasion that your choices
are not showstoppers, are what gets a library accepted.

After all I'm definitely not the only person who has implemented HTTP
half a dozen times, and is likely looking at your library and wondering
about the design assumptions too. It's just they haven't said it yet
because our dialogue was answering their questions. So even if you and
me stop, you may well see the exact same themes - though perhaps more
tactfully put than from I - being raised anyway.

I particularly strongly weigh Bjorn's opinion, we used to work at the
same employer for a bit where we developed a replacement for TCP
extending ASIO, and where HTTP was going to be deployed over that.
Interestingly Beast would likely have worked just fine on that as it was
ASIO based, but we very nearly didn't choose ASIO as the base, in which
case Beast would have been useless to us. So if he greenlights you, I'm
happy, if not, then you should take the feedback he gives you very
seriously. He really knows his stuff.

Niall