On Sat, Jul 1, 2017 at 1:38 PM, Niall Douglas via Boost
At the very minimum, I think Beast needs to become two, separate libraries: (i) the HTTP utility library (ii) WebSocket.
Beast is proposed as-is.
The natural split point for Beast into multiple, focused libraries is between the code which only concerns itself with structured data, and everything else.
Beast is proposed as-is.
So why are you forcing end users to drag in ASIO?
Beast will be part of Boost, whose distributions include Asio. To use
serializer or basic_parser, the header
The reason why according to you is for the buffer infrastructure. But as I've already told you, that's a relic from a decade ago. New code neither ought to nor needs to use that. We have far better available today.
That "relic from a decade ago" is in the latest Boost 1.65.0. As I have targeted Boost.Asio specifically, you will naturally understand that Beast uses that buffer infrastructure for better or for worse. When a version of Boost.Asio appears which is "far better", then Beast will be ported to it. The stand-alone Asio is already a bit ahead of Boost.Asio in its buffer technologies; since you feel that Boost.Asio is so far behind perhaps you can take on the task of porting stand-alone Asio's changes to Boost?
And if the really reusable parts of Beast, the ones not dependent on ASIO except for some buffer adapters, can be broken off and be made free of ASIO, that's a big value add to end users who don't need WebSocket and just want a HTTP utilities library.
Eliminating the dependence on Asio's buffers is something that is on
my horizon, but it is not a feature for the library being proposed.
There hasn't been much demand for using the parser or serializer
without
WG21 has much superior vocabulary types for doing buffer sequences than ASIO's which are needlessly complex, over engineered, and over wraught
Please specify the WG21 vocabulary types you are referring to. The Ranges TS is an obvious place to start from as a source of Concepts
Until you file the LEWG issue where you describe N4588 buffer sequence concepts as "needlessly complex, over engineered, and over wraught[sic]" and provide an alternative in the form of proposed language, there is nothing actionable in your statement.
Very little in your library has, or ought to have, anything to do with i/o. .. Stop thinking in terms of i/o. HTTP is just structured data. So treat it as such. Parse as structured data, generate as structured data.
Is my understanding correct that you say Beast should not provide functions to send and receiving HTTP messages using Asio streams? Thanks