Re: [boost] [review][beast] Five-days Remaining

Subject: Re: [boost] [review][beast] Five-days Remaining
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-06 07:24:11

On Wed, Jul 5, 2017 at 11:51 PM, Gavin Lambert via Boost
<boost_at_[hidden]> wrote:
> 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-July-1-July-10-tc4696294.html#a4696441>

> 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