On Tue, Jun 27, 2017 at 1:30 PM, Artyom Beilis via Boost
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/7b0d48281049c3fec7fafcb7ce5cea045367a... [2] http://vinniefalco.github.io/beast/beast/design_choices/http_comparison_to_o... [2] http://vinniefalco.github.io/beast/beast/using_networking/asio_refresher.htm...