Boost logo

Boost :

Subject: Re: [boost] [review][beast] Five-days Remaining
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-07-06 06:51:57

On 6/07/2017 17:19, Michael Caisse wrote:
> We are half-way through the review and have some great involvement and
> exchanges and a few reviews already.
> I hope if you haven't written a review yet that you still will. Please
> provide whatever effort you can afford toward the review process. Boost
> depends on community involvement.
> You might have noticed that I have solicited input from you regardless
> of your experience with the domain. I personally think it is a mistake
> to have input only from domain experts. True innovation often comes from
> "outsiders". If you have no experience with Asio or with HTTP, how
> approachable is this library? Were you able to understand the documents?
> Could you use the examples? Were you able to build something of your own?

I'm probably not going to post an actual formal review (since I haven't
looked closely enough at it) but I did have some thoughts:

1. The name is more than a bit silly; while silly names are not in
themselves a problem (see Hana, Spirit, etc, and the FAQ that brings up
the same argument), this one sounds like it was chosen simply because it
was phonetically similar to "Boost", which seems potentially confusing
at the least.

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.

Perhaps I just have the wrong impression of something from the docs, but
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), but then the
WebSocket part goes beyond that to include actual socket management and
connection lifetimes.

This impression was reinforced from some earlier discussion about the
different interfaces between the HTTP part (which is stateless static
methods) and the WebSocket part (which is stateful instance methods).

If this impression is correct, it seems like it would be better to split
Beast into two separate libraries; one that is "more" low-level and has
just the HTTP (and perhaps WebSocket) stateless parsing and generation
components only, and then a second library sitting on top of this that
provides the WebSocket connection management. Perhaps similar to how
the author brought up possible future HTTP server/client libraries as
extensions on top of Beast.

3. The documentation seems extensive, well-written, and easy to follow.
(I count myself as reasonably familiar with both Asio and HTTP, although
not an expert.)

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at