On Mon, Dec 3, 2018 at 7:45 AM Cristian Morales Vega via Boost-users
There are lots of things which I would expect to be in Boost.Asio which are actually in Boost.Beast. Why?
Most of it is "helping" code/docs. For example: - Documentation about (and public interfaces to simplify) the creation of composed operations https://www.boost.org/doc/libs/develop/libs/beast/doc/html/beast/using_io/wr...
It states very clearly in the Beast documentation, that an understanding of Asio is required. Of course, this doesn't stop people who are new to Beast, new to Asio, new to Networking, new to C++, new to programming (or all of the above) from picking up the library and trying to implement something. It is true that there is a notable lack of authoritative tutorials and guides on all of the finer aspects of using Boost.Asio (and by extension, stand-alone Asio and Networking TS). I don't think it is fair to expect that the author of Asio (Christopher Kohlhoff) should be responsible for writing these things. I expect this situation to change once Networking TS is merged into the standard. By making networking a standard, it reduces the risk and increases the incentive for authors and publishers to produce these missing educational materials. As far as networking goes, I believe C++ is behind largely because of decisions made by wg21, which is the ISO group responsible for updating and producing the C++ standards. Fortunately, competition and pressure from other languages has lit the proverbial fire and networking is finally being taken seriously (although some people, like myself, think that fire could be stoked a bit).
- beast::buffers_cat
I follow Chris' design work closely and I think his "layered" approach is the right way to build up libraries. Asio provides the low level building blocks which cannot be further decomposed without losing portability. My opinion is that most C++ users should not be writing code for Asio or Networking TS. These interfaces are mainly designed for building layers on top of it, layers such as Beast. End users want to perform an HTTP GET to retrieve a file using a single line of code. They don't want to have to know about the intimate details of the protocol. Even Beast could be considered too low-level for most end-users. I wrote Beast mainly as a run up in the ladder of abstractions, so that other people could build on it. With respect to buffers_cat, yeah - it is really handy! There is no question that it has utility. Although I don't know that Asio is the place for it. There are other ways to implement buffers_cat with different tradeoffs. For example, you could use a fixed C-style array of const_buffer. This would accomplish type-erasure at the expense of a larger structure. That said, I have proposed some of Beast's buffer sequence adaptors for the standard library: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1145r0.html
- beast::test::stream (to be fair, it's in experimental)
Interfaces in _experimental/ are very likely to change which is why they are specially marked. They can also have bugs or lack documentation. As these things become fully baked they will be promoted to public interfaces (moved from _experimental to one of the public interface directories).
But now we even have code to work around issues in Boost.Asio which ideally would simply be fixed in Boost.Asio. For example: beast::ssl_stream.
asio::ssl::stream implementation does not handle scatter/gather I/O. When you call write() with a buffer sequences having length greater than one, it results in a separate I/O for each element of the sequence. This kills performance, especially in Beast where the implementation makes heavy use of buffers_cat. Beast's ssl_stream class is a wrapper which intelligently flattens these sequences at the expense of allocating memory. I think there's an OpenSSL interface for handling a vector of buffers, so if it was fixed in Asio it would be better as there would be no need to allocate memory. I don't know enough to attempt a fix but maybe there is someone else who could?
I am asking myself how to handle an increasing amount of references to Beast that in a future could change to Asio (potentially with slightly different names/semantics). So I am writing this hoping for some light on the situation.
Well, you can be ready with the find and replace tool :) Regards