pt., 27 sty 2023 o 20:35 Vinnie Falco via Boost
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/a3a284f06597ad12ca6cc1782bebb...
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;