Re: Boost.Buffers: network-agnostic buffer types and algorithms

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2023-01-27 20:04:12

On Fri, 27 Jan 2023 at 20:35, Vinnie Falco via Boost <boost_at_[hidden]>
wrote:

> Greetings. I am asking if there is any interest in a Boost.Buffers

library, which consists of the following:

> * ConstBuffer, MutableBuffer concepts
> * ConstBuffers, MutableBuffers concepts
> * const_buffer, mutable_buffer types
> * DynamicBuffer concept
> * `source` and `sink` abstract interfaces used to
>   define the Source and Sink concepts
> * metafunctions for checking all type requirements
> * implementations of common buffers and dynamic buffers:
>   - buffers_pair
>   - array_of_buffers
>   - circular_buffer
>   - dynamic_string_buffer
> * Algorithms:
>   - buffer_copy
>   - buffer_size
>
> The twist is that this library has no dependency on Asio or Boost.Asio
> (but Asio will still recognize them thanks to some template heroics
> and a splash of forward declarations). Why am I proposing this? Well,
> let me tell you some things...
>
> I am currently working on these two libraries:
>   Boost.Http.Proto
>   Boost.Http.Io
>
> The Proto library implements HTTP/1 to a fuller feature set than Beast
> and fixes all the design flaws in Beast (but it is completely not API
> compatible). This library does not do any network I/O, it is expressed
> purely in terms of buffer concepts (i.e. depends on Boost.Buffer and
> not Boost.Asio).
>
> The Io library depends on Asio and the Proto library to provide the
> network algorithms which use Asio to implement HTTP/1. This is the
> equivalent HTTP functionality of what Beast offers today.
>
> Websockets is not included but when I am done with Http I will redo
> websockets with improvements and new features, and similarly they will
> be developed as two libraries:
>
>   Boost.Websockets.Proto
>   Boost.Websockets.Io
>
> My motivation for splitting libraries this way is as follows:
>
> * Each library is smaller and compiles more quickly
> * CI turnarounds are faster
> * Separation of concerns
>
> The HTTP Protocol library is designed in a way that much of an
> application's HTTP business logic can be expressed independently of
> Asio using only the constructs found in Http.Proto. This especially
> means fewer templates and faster compilation because Http.Proto is
> designed from the ground up to avoid templates whenever possible.
>
> However during the development of Http.Proto I find myself having to
> reach for the same buffer algorithms and containers that I developed
> for Beast (such as the circular buffer and the dynamic buffer). So
> Http.Proto has been steadily growing these things:
>
> <
> https://github.com/CPPAlliance/http_proto/blob/a3a284f06597ad12ca6cc1782bebbba04d9cbf8e/include/boost/http_proto/buffer.hpp
> >
>
> Extract this independent buffer functionality into a separate library
> Boost.Buffers would bring these benefits:
>
> * Again a smaller library, faster compilation
> * Faster CI turnarounds
> * Separation of concerns
>

Personally I think that the idea has merit on the basis of separation of
concerns alone.

>
> Additionally, algorithms can be expressed in terms of asio-independent
> buffer types and concepts. For example, Boost.JSON could implement the
> boost::buffers::sink and boost::buffers::source interfaces which would
> enable its use in Boost.Http.Proto and Boost.Requests (an upcoming
> HTTP client library from Klemens), without having to depend on either
> of those libraries or Asio.
>
> Is this style of development of smaller, fine grained libraries that
> separate concerns something that is desirable for Boost? Glad for any
> feedback.
>

>
> --
> Regards,
> Vinnie
>
> Follow me on GitHub: https://github.com/vinniefalco
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>