Re: [boost] [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!

Subject: Re: [boost] [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-10-04 15:02:52

On Wed, Oct 4, 2017 at 7:51 AM, paul <pfultz2_at_[hidden]> wrote:
> Ideally, the constructor to `buffer` or `const_buffer` should take any class
> that has a `.data()` and `.size()` member. This way `value_type` can fulfill
> the requirement of `ConvertibleToBuffer` without needing the dependency on a
> concrete type.

That is quite a good idea! But that would require a change to the
Networking-TS which means writing a paper. And it would have to be
changed in Asio as well, since we're modifying the meaning of a
concept.

> Another option, is just moving these concrete buffer classes from Asio to your
> new library...

Yes, that is the approach that I am taking with Boost.Buffers

>...and then Boost.Asio will depend on Boost.Buffers.

Of course that would be great, but I can't presume that the author
would be open to making that dependency. We also have to be mindful
that stand-alone Asio is the upstream library - Boost.Asio is
generated from stand-alone Asio via script. In order to make
Boost.Asio depend on Boost.Buffers some accomodation would need to be
made.

However, making Boost.Asio depend on Boost.Buffers is not strictly
necessary, I have a work-around that lets the user decide where to get
the header files from:
<https://github.com/vinniefalco/buffers/blob/30ef7031ec0909972a720c0cdd8d6c6e1cc9e37b/include/boost/buffers/asio.hpp#L13>

I plan on moving beast's dynamic buffer implementations and buffer
adapters into Boost.Buffers as well, I will describe this plan in a
new post shortly.