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
> 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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk