Re: [boost] [Beast] Questions Before Review

Subject: Re: [boost] [Beast] Questions Before Review
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-06-27 21:28:12

On Tue, Jun 27, 2017 at 1:30 PM, Artyom Beilis via Boost
<boost_at_[hidden]> wrote:
> It was pointed that ripple uses beast. What it used for?
> What is implemented using Beast?

Ripple implements an HTTP and WebSocket service which uses a JSON
interface to interact with the Ripple network (a decentralized ledger
with a built-in cryptocurrency). [1]

> If it is barely HTTP headers parser what do I need it for?

Parsing HTTP messages is just one great feature of Beast. Other great
features include:

* An HTTP message model
* Read HTTP message to stream synchronously
* Read HTTP message to stream asynchronously
* Write HTTP message to stream synchronously
* Write HTTP message to stream asynchronously
* Built-in chunked encoding codec
* Obtain a serialized buffer representation of an HTTP message
* Produce an HTTP message from serialized buffers
* A full WebSocket implementation
* Classes for implementing composed operations
* Adapters for working with buffer sequences
* Metafunctions to determine if a type meets a concept
* New models of DynamicBuffer
* static_string

Some users have a need to create an HTTP message and send it, or to
receive an HTTP message and process it. Sometimes it is in the context
of a web server or general HTTP client but not always. Often they want
to use WebSocket.

A programmer who just wants to send and receive an HTTP message from
within their code has to do what exactly? Link with the CppCMS
framework? Include a copy of cUrl in their app? They can use Beast for
that. And they *are* using Beast for that, the library is steadily
growing in users and popularity.

In particular, Beast's message model is quite robust with lots of
customization points. Its been designed to avoid the flaws exhibited
in other libraries [2]

> Looking over examples I noticed that the library user needs to manage
> all timeouts/keep alive connections. Am I right?

Yes, and this is also stated in the documentation. With a big red
WARNING sign [3]

> Why should I choose to write something over beast
> when there quite a lot of good solutions providing much
> more (higher level interface)

That's a great question. There are quite a few Beast users now, the
GitHub issues have been lively and I have received many emails of
thanks (and even more emails asking for help!). Apparently some people
are finding Beast quite useful. If you think that there are other
solutions which are better suited for your purpose, I am not
surprised, Beast was not written to solve all problems. Just to handle
the cases for which it was written.

One area where Beast has a likely advantage, is that it is more suited
for standardization (inclusion in the C++ standard library) than any
other library. For exactly the reason underlying your questions - it
doesn't try to do too much. But what it does do, it does correctly.
More specifically I am making this claim:

* Beast demonstrates what a standardized, low-level implementation of
HTTP should look like

To put it bluntly, any program which is not sending and receiving HTTP
messages in a fashion similar to Beast (and eventually, using Beast
explicitly) is likely doing it wrong, to the same extent that someone
who insists on implementing their own version of common objects found
in the standard library are doing it wrong (granted there are some
special cases).

> I'm not telling this to discourage you I'm telling it because Beast looks to me more like
> a tiny layer above socket or an assembly language for HTTP handling.

Yes!

Here comes the shocker...quite a few people prefer Beast over other
libraries judging from the activity in the repository and feedback
I've received. Because it doesn't impose odd choices on its users.

Its exactly what you said, a thin protocol layering on top of Asio.
Beast implements just enough of the HTTP protocol to get messages in
and out and leaves the "odd choices" up to users. I think that's how
it should be for a low level library. And I think that C++ and Boost
in particular, needs this low level component.

> And I'm not talking about basic higher level stuff like forms CSRF, security
> sessions etc.
>
> I mean HTTP itself was tiny part of the problem, the hard problems
> that may interest the library/framework develop are out of Beast scope.

Well, I don't know that I agree with that. One of Beast's most
important features is how closely it tracks Asio interfaces and best
practices. I have gotten feedback from users that this is one of the
greatest strengths. Of course, if someone is allergic to Asio then
they will similarly be allergic to Beast.

To say that HTTP itself was a "tiny part of the problem" is I think to
disregard the enormous effort and problem solving that went into
getting Beast to where it is. Even if I were to agree and say it was a
tiny part of the problem, it is a part that has not been satisfied to
a thorough degree and of a quality sufficient to have a chance at
Boost acceptance or C++ standardization.

...and it has WebSockets :)

Thanks

[1] https://github.com/ripple/rippled/tree/7b0d48281049c3fec7fafcb7ce5cea045367ae1f/src/ripple/server/impl

[2] http://vinniefalco.github.io/beast/beast/design_choices/http_comparison_to_other_librari.html

[2] http://vinniefalco.github.io/beast/beast/using_networking/asio_refresher.html