Hello,
This is my formal review of Boost Beast.
> What is your evaluation of the design?
Also the general design is solid provides generic API that does the
job it defined.
The most problematic issue with Beast is it total reliance on static
polymorphism. This comes to sometimes very painful issues like:
Having the object code duplicated for different variants HTTP/HTTPS code
Having all the implementation in headers increasing compilation time
Adding complexity to end user since he needs to propagate the
templates to various places.
Virtually all concepts could be done with classic interfaces and
virtual functions.
Using of static polymorphism does not provide there performance
advantage but reduces code maintainability and adds lots of headache
to end user.
Note: it does not contradict of using ASIO but lots of stuff could be
pimpled or hidden having only few forward declarations of the relevant
classes.
> What is your evaluation of the implementation?
>From what I seen didn't find may flows besides thous mentioned before
(content-length - that was fixed) and non-blocking sockets aren't
covered by tests.
However I didn't look too much since the code is quite hard to read
being too template heavy.
Second major issue is that it puts all the heavy work on end user
providing tiny parsing messaging layer that to be honest is the simple
part of HTTP handing.
It significantly limits its usability to virtually void.
> What is your evaluation of the documentation?
Documentation is OK - similar to ASIO - I think more examples should
be needed and tutorials regarding how to do common tasks.
> What is your evaluation of the potential usefulness of the library?
VERY limited.
The library does too little to be useful for real development.
I don't really see a real need for a library that could potentially be
used to create CURL or could potentially be used to write web
framework that users will work over them.
As a user of this library you need to deal with:
- User has to have deep knowledge of HTTP protocol itself and be
highly aware of various security related problems on WWW.
- Protocol itself and know it up to the small details, timeouts and much more.
- Being able to parse all parameters passed from getting query string,
parsing multipart/form-data (a.k.a. file upload format) parse percent
encoding, cookies. I suggest to drawing the line at some point when
library becomes useful for somebody who for examples needs to
implement RESTful service or send some post data to a form.
The separation line that was drawn does not suite the needs of too
many of potential users. I understand it is huge task to do but if
first lines in your FAQ and many other talk about what the library
doesn't do than probably something goes wrong.
And please note I don't talk about sessions, url mapping, but much
more basic stuff like multipart parsing, url-encoding. URL parsing,
> Did you try to use the library? With which compiler(s)? Did you have any problems?
Tried to compile several examples no problem.
> How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
At least 10-12 hours of reading documentation, code, running some
examples. Notifying potential problems.
> Are you knowledgeable about the problem domain?
Yes, I'm myself an author of CppCMS C++ Web Framework - fully featured
web development platform for C++ that works in both synchronous and
asynchronous modes, I implemented HTTP and FastCGI protocols,
networking engines myself. Designed high performance services and
more.
> Should the library be included to Boost?
Unfortunately NO.
Two major reasons:
- Abuse of static polymorphism where classing object oriented design
with virtual functions can do better job.
- The scope of the library is way too limited that it brings the
question of its usability for real users.
I fully acknowledge the huge high quality work the author did -
something that kept me reviewing the library and providing the
comments, but the library as it is today IMHO doesn't suit Boost
Best Regards and Good Luck,
Artyom Beilis
