On 01/07/2017 17:02, Vinnie Falco via Boost wrote:
- For this collection of HTTP-related library routines...
It seems that WebSocket is the red-headed stepchild that no one talks about. Of course, I understand that the HTTP portions of Beast are far more interesting (controversial?) so I guess we'll be talking about that for most of the review.
Beast WebSocket belongs in another, separate library. That library could bring in ASIO as a dependency.
I do not see why any awareness of ASIO is needed at all.
Also stated in the documentation: "...using the consistent asynchronous model of Boost.Asio." http://vinniefalco.github.io/beast/beast/introduction.html
I don't get why it's needed,
Boost.Asio is effectively what will become the standard way to do C++ networking (i.e. N4588). Beast recognizes that C++ will soon have a common, cross-platform networking interface and builds on that interface exclusively.
I snipped all the hand waving as irrelevant to the question I posed, which it is. You didn't answer the question. These are the stated things Beast provides: 1. Message containers 2. Stream reading 3. Stream writing 4. Serialisation 5. Parsing ... which seem a reasonable and useful subset of HTTP to implement. You have told me no reason why any of these needs a hard dependency on any networking implementation, or awareness of any specific networking design pattern. I personally can see no good reason why they should be: **HTTP has nothing to do with networking**. It therefore seems to me that reading ought to be calculated views of underlying byte data, and writing ought to be compositing a sequence of byte spans to gather into a send. Like the Ranges TS does. Please convince me that I am wrong. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/