Boost logo

Boost :

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-02-02 21:57:55


pt., 27 sty 2023 o 20:35 Vinnie Falco via Boost <boost_at_[hidden]>
napisał(a):

> 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
>
> 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.
>

This is an idea certainly worth exploring. Let me share some random
observations.

The idea of vocabulary types is great and I would like Boost to be the
place for hosting them. In the past, vocabulary types were `optional`,
`tuple`, `variant`, `shared_ptr`. Today the basics for networking seems
like good candidates for vocabulary types. Is Boost.Buffer a candidate for
such a vocabulary type?

First question, is this library to be consumed directly by user programs,
or only by other libraries, such as Boost.Beast and Boost.Http.Proto?

Is it possible that the final program that uses Boost.Buffer will not use
Boost.ASIO?

For me, as a consumer of networking libraries, who can afford to download
and build the entire set of Boost libraries, the biggest advantage would be
that Buffers would be well documented and tested.

I am not convinced by the argument with Boost.JSON not depending on ASIO.
We have (I think a still unresolved issue) of Boost-serializing
Boost.Optional. Should the code responsible for the serialization of
Boost.Optional be part of Boost.Serialization or Boost.Optional? But we
will certainly not solve it by introducing yet another library. There are
other ways to solve it, say, through optional headers. Also, Boost.JSON
doesn't need to depend on the implementation of the circular buffer. But
here I am only criticizing the argument with Boost.JSON, not the idea to
factor out Boost.Buffers.

Regards,
&rzej;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk