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

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 
somewhere.