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.