On Wed, Jul 5, 2017 at 11:51 PM, Gavin Lambert via Boost
2. The design rationale makes a big deal of limiting the scope of the library and being low-level. That's fine (and a good thing, in my opinion), but it makes me question what the WebSocket part is doing there.
`beast::websocket::stream` is a low level protocol layering on top of Boost.Asio, just like HTTP is. You have to establish the connection yourself, maintain timeouts, manage a send queue for writing, and that sort of thing.
it seems like the HTTP part is focused on simply parsing and generating the HTTP message format (and thus conceptually could do so with any stream abstraction, including a non-socket-based one)
Against which yet-unspecified stream abstraction do you feel Beast's algorithms should be written? The rationale for the current choice of using Boost.Asio's stream abstractions is explained here here: http://boost.2283326.n4.nabble.com/review-beast-Review-of-Beast-starts-today...
but then the WebSocket part goes beyond that to include actual socket management and connection lifetimes.
Which socket and connection lifetime management features are you referring to?
4. In the FAQ "There's no HTTP/2 support yet!" the phrase "Users cannot work with HTTP/1 now" does not make sense and I suspect there's a typo somewhere.
You're right about that, someone else pointed this out in their review (its been fixed in a new branch). I meant to say that we shouldn't wait for HTTP/2 to give users HTTP/1. Thanks