During the formal review of Beast, desires were expressed to use
components like the HTTP parser and serializer independently from the
rest of the library. The sticking point was the abstraction used to
represent a range of non-owning buffers. In particular, Asio imposes
certain concrete type requirements in its ConstBufferSequence and
MutableBufferSequence concepts.
It would seem there is significant interest in making some components
of Beast modular, in their own libraries. The main feature of these
components would be that they should not require Boost.Asio.
Unfortunately, the way Asio's concepts are defined this is not
possible.
Two solutions present themselves:
1. Create a new buffer sequence concept which retains all the features
of Asio's concepts but does not require the concrete types. While this
is possible it would create a significant complication. Interfaces
which use the new concept would require some kind of adapter at every
call site that tries to use a traditional Asio style interface.
2. Create a new library which uses conditional compilation to either
include just the Asio header files which fulfill the needs for
interacting with buffer sequence concepts, or provide the declarations
directly from a copy of the Asio sources.
The solution used in Boost.Buffers (a new library I am considering
proposing) is choice number two.
Someone who wants to create a new library ("Foo") that does no network
I/O but wants to interoperate with Asio buffer concepts merely need to
do the following
#include