On Tue, Oct 3, 2017 at 2:23 PM, paul wrote:

How do the Buffer concepts change to depend on networking? The way the buffers are defined now, there is no dependency on Boost.Asio.

Are you suggesting that the Net-TS buffer concepts do not depend on Boost.Asio? That's not entirely correct. Net-TS buffer sequence iterator value types must be convertible to `std::experimental::net::const_buffer` or `std::experimental::net::mutable_buffer`. In the Net-TS compatible version of Asio these types are `boost::asio::const_buffer` and `boost::asio::mutable_buffer`. There is simply no way to avoid the dependency on these concrete types in Asio. In my other post I am proposing a library Boost.Buffers to work around this problem, so that people (like me) can write libraries which use only Asio buffer concepts, without a dependency on all of Asio (and everything that Asio depends on, recursively). Thanks

On Wed, Oct 4, 2017 at 7:51 AM, paul 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/30ef7031ec0909972a720c0cdd8d6c6e... 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.