Collaboration with Beast?

[vinniefalco]

Beast is a new header-only library using Boost that offers HTTP and WebSocket support (disclaimer: I'm the principal architect). Here's the home page with links to the repository, documentation, example code, and Autobahn test results (for the WebSocket component):
http://vinniefalco.github.io/

I'm wondering if this library could be a useful building block for cpprestsdk? There's some overlap in functionality and I think that Beast offers some very interesting design choices which at worst could serve as inspiration for future improvements to cpprestsdk and at best might be sufficiently useful as to motivate use of the library directly in the project.

For example, I notice in the cpprestsdk that the message model (class http_msg_base) conflates both message representation and message serialization/sending:

class http_msg_base
{
...
    _ASYNCRTIMP void set_body(const concurrency::streams::istream &instream,
                              const utf8string &contentType);

https://github.com/Microsoft/cpprestsdk/blob/3070ca21ed665a5aeb7d0cfe28f7f21d6c062a92/Release/include/cpprest/http_msg.h#L236

Beast solves this problem a different way, the message model supports a Body template argument with traits that give instructions on how the message is serialized. The choice of body controls the container used to represent the body (for example, std::string, a boost::asio::streambuf, or a user-defined type) and the means to serialize that body to a set of buffers:

beast::http::message class
https://github.com/vinniefalco/Beast/blob/47eb7fcc2f30df883b0036d97aac6a0fa90b0e9f/include/beast/http/message.hpp#L49

Body concept:
http://vinniefalco.github.io/beast/beast/types/Body.html

Writer concept (serializes the body)
http://vinniefalco.github.io/beast/beast/types/Writer.html

Here's an example of a type that meets the requirements of the Body concept:
https://github.com/vinniefalco/Beast/blob/47eb7fcc2f30df883b0036d97aac6a0fa90b0e9f/examples/file_body.hpp#L32

Beast also offers a WebSocket implementation that follows Asio best practices and has quite a few things going for it

Beast is targeted not at end-user developers who want to do simple things like fetch a webpage or submit a request to a REST service but instead is aimed at library writers, I think this might be a good fit.

[vinniefalco]

Is this proposal not well received? Should I close it?

Regards

[ras0219-msft]

Sorry for the long delay on this. I had intended to fully investigate Beast before responding, but I never got time to complete that (I still haven't, but I can at least speak to the general approach we'll take here).

First, as you would certainly understand, taking on another dependency is huge. Generally, we'd like to only take dependencies on libraries that are more mature and used than ourselves. Currently, we only use Boost, websocket++, openssl, and zlib. Looking at the metrics on the Beast page (https://github.com/vinniefalco/Beast), I don't see the kind of maturity metrics we'd really want in a dependency (project history, number of significant contributors, stars/word of mouth popularity).

From the brief look at Beast that I did, I would like to say that from a technical perspective, I do like the library. I agree that (from my cursory inspection) the layout you've chosen seems solid and would be a good way to organize the problem.

So my qualms are primarily with project maturity and not instantaneous technical excellence. To compensate from the lack of project maturity, it would cost a lot of time in extensive code reviews, so the potential benefits would need to be really big to justify looking into that over the usual of fixing other user's issues and answering questions.

Now, looking at Beast as a inspirational design model instead of taking a dependency is much more interesting to me. As I stated above, your API design seems solid as far as I've seen; I'd be quite interested in comparing it to our current APIs and seeing how we can incrementally improve by including the idioms and paradigms you've discovered. I would very much value any comments you have about flaws in our existing APIs, like the comparison you've already made w.r.t. the message model.

We have a strong commitment to source-level compatibility, so we can't make large sweeping changes, but things like adding overloads to existing APIs and extracting concepts into separate structures seems very doable.

[vinniefalco]

@ras0219-msft Your thinking closely resembles mine. There's a broad range of possibilities for collaboration, the extreme of course is taking Beast on as a dependency but as you pointed out, an exercise in comparing designs and seeing how our respective projects could be improved independently could still be fruitful. For example, I could improve interfaces in Beast that would be an obstacle to a potential integration. Or ideas from Beast's message model could be leveraged in cpprestsdk without introducing a source-level incompatibility.

[vinniefalco]

About the WebSocket support, here's a response when someone asked about the difference between websocketpp versus Beast:
http://lists.boost.org/Archives/boost/2016/04/229342.php

Note that permessage-deflate (message compression and decompression) is already in development in Beast (see https://github.com/vinniefalco/Beast/commits/deflate) and will feature a header-only C++ implementation of zlib (one less dependency).

[vinniefalco]

I'll be presenting a talk on Beast HTTP/WebSockets at CppCon 2016 (Sep 18-23) if anyone is interested, I will be there giving the talk and I can ask questions and interact during the convention. Hope to meet some wonderful new C++ folks there! Thanks

[vinniefalco]

Update:

I've continued to actively develop Beast since I opened this issue. The library is scheduled for a Boost formal review for the first week of July 2017. Fingers crossed! Any feedback welcomed.

[vinniefalco]

I would very much value any comments you have about flaws in our existing APIs, like the comparison you've already made w.r.t. the message model.

I'm working on this now. it will be available before the Boost formal review of Beast.

[vinniefalco]

High time this is closed :)

[timrae]

@ras0219-msft
Still no plans to consider using Beast behind the scenes now that it's in boost?

@vinniefalco
You make it pretty clear that the target users of Beast are library developers rather than "end-users". Are you aware of any such higher level libraries that are using Beast?

p.s. congratulations on getting the library accepted, and also on your outreach efforts like in this issue; it's great to see!

[soroshsabz]

@ras0219-msft And now boost beast is very better than past year, last update release in in boost 1.70