[boost] Fwd: [review][beast] Review of Beast

Subject: [boost] Fwd: [review][beast] Review of Beast
From: Michael Caisse (mcaisse-lists_at_[hidden])
Date: 2017-07-06 17:41:36

I received this review as a private email from Stanislav who has
indicated that I may share it on the list.

-------- Forwarded Message --------
Subject: 	[boost] [review][beast] Review of Beast
Date: 	Thu, 6 Jul 2017 20:23:26 +0300
From: 	Stanislav Karchebnyy <hidden>
To: 	mcaisse-lists_at_[hidden]

Good day!

I'm not a very good writer in english, so i tried to keep it short and
to the point.

- What is your evaluation of the design?

I believe it fits well with asio style.

- What is your evaluation of the implementation?

I like the modularity and composability of the library, e.g. various
buffers that comply with asio interfaces. Also use of helpful typedefs
makes code a lot easier to read. Code style is almost declarative (which
is a good sign in my book).

- What is your evaluation of the documentation?

Documentation is good, although some methods are documented a little
short and a bit tautologically. This is not specific to beast however,
seen it in many other boost libraries.

  - What is your evaluation of the potential usefulness of the library?

It is immensely useful as it is already. See below for the example.

  - Did you try to use the library? With which compiler(s)? Did you have
any problems?

Currently I’m developing with Beast on latest OSX with clang. It
compiles cleanly and runs quite well. The aim is to later use it also on
Linux with gcc.

  - How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

I’m in process of converting our POCO-based networking code for
HTTP/HTTPS client and Websocket client to Beast.

I started with Websocket and it was a pleasant and rather quick
conversion from POCO-style ActiveDispatcher methods (which are ugly with
binds and tuples for argument packs) to truly asynchronous beast
websocket implementation.

We use own protocol running on top of websocket frames, and with beast
it was really easy to implement. That beast is a construction framework
and does not have unnecessary boilerplate made it quite easy to plug our
own parsing engine directly on top of websocket frames.

Code became much cleaner as a result. I did not do speed benchmarking
yet, as I’m still in development phase, but I’m much more concerned
about maintainability in this project and beast made it a lot better -
unfortunately I cannot share the code, but now I can trace the state
transitions with a glance, instead of digging through bunch of POCO
tuple-ridden methods. Another improvement is the fact that POCO
websocket uses a dedicated listener thread for input, while beast
utilises proper asio design.

Beast comes with quite good examples, that covered about 90% of my
questions during transition, the rest was answered by Vinnie himself. He
is very responsive and helpful as a library maintainer.

  - Are you knowledgeable about the problem domain?

Yes, I know how http and websocket things are supposed to work.

My overall impression with the library and its author helpfulness
suggests that ACCEPT to boost is a reasonable move.

-- 
Sr. Software Engineer
twilio <http://www.twilio.com/?utm_source=email_signature>
EMAIL
           hidden