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: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-01 21:15:38

On Sat, Jul 1, 2017 at 1:38 PM, Niall Douglas via Boost
<boost_at_[hidden]> wrote:
> At the very minimum, I think Beast needs to become two, separate
> libraries: (i) the HTTP utility library (ii) WebSocket.

Beast is proposed as-is.

> The natural split point for Beast into multiple, focused libraries is
> between the code which only concerns itself with structured data, and
> everything else.

Beast is proposed as-is.

> So why are you forcing end users to drag in ASIO?

Beast will be part of Boost, whose distributions include Asio. To use
serializer or basic_parser,  the header <boost/asio/buffer.hpp> must
be included, which is a pretty self-contained file. This is a
temporary situation until Boost.Asio is updated to N4588.

> The reason why according to you is for the buffer infrastructure. But as
> I've already told you, that's a relic from a decade ago. New code
> neither ought to nor needs to use that. We have far better available today.

That "relic from a decade ago" is in the latest Boost 1.65.0. As I
have targeted Boost.Asio specifically, you will naturally understand
that Beast uses that buffer infrastructure for better or for worse.
When a version of Boost.Asio appears which is "far better", then Beast
will be ported to it.

The stand-alone Asio is already a bit ahead of Boost.Asio in its
buffer technologies; since you feel that Boost.Asio is so far behind
perhaps you can take on the task of porting stand-alone Asio's changes
to Boost?

> And if the really reusable parts of Beast, the ones not dependent on
> ASIO except for some buffer adapters, can be broken off and be made free
> of ASIO, that's a big value add to end users who don't need WebSocket
> and just want a HTTP utilities library.

Eliminating the dependence on Asio's buffers is something that is on
my horizon, but it is not a feature for the library being proposed.
There hasn't been much demand for using the parser or serializer
without <boost/asio/buffer.hpp>. But if that were to change, I would
likely reprioritize the feature. A port to N4588 will automatically
solve the problem.

>>> WG21 has much superior vocabulary types for doing buffer sequences
>>> than ASIO's which are needlessly complex, over engineered, and over wraught
>>
>> Please specify the WG21 vocabulary types you are referring to.
>The Ranges TS is an obvious place to start from as a source of Concepts

Until you file the LEWG issue where you describe N4588 buffer sequence
concepts as "needlessly complex, over engineered, and over
wraught[sic]" and provide an alternative in the form of proposed
language, there is nothing actionable in your statement.

> Very little in your library has, or ought to have, anything to do with i/o.
> ..
> Stop thinking in terms of i/o. HTTP is just structured data. So treat it
> as such. Parse as structured data, generate as structured data.

Is my understanding correct that you say Beast should not provide
functions to send and receiving HTTP messages using Asio streams?

Thanks