On Tue, Oct 24, 2017 at 6:04 AM, Osman Zakir via Boost-users
Boost.Beast is a library that only provides low-level support for HTTP? But what does that mean, exactly?
Beast provides: * A universal container for holding HTTP messages * Algorithms for sending and receiving messages on streams * A WebSocket stream implementation
What will users not be able to do with it,
Beast does not manage the socket for you. So you have to create the listening socket yourself, accept connections, make outgoing connections, shut down the connection. For SSL you have to use Asio to manage certificates and verification. But Beast will work with SSL streams once you have them set up. You need to take care of timeouts yourself.
and is it good to be used for creating a HTTP server and client that can handle at "get" and "post" requests?
I think so. Have a look at the example servers: http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/examples.html
I want to build a currency conversion app that takes rates from the web in real time, so I need a server and client that can handle at least that if nothing else. Though I may need a client for other, more advanced things later on as well.
I think this could be done in Beast, you can make a copy of the example client and servers and modify it from there. If you have questions or need help feel free to open an issue in the repository, I am very responsive.
It's an interesting name, though. Is there any special reason behind the name? Just wondering.
Check the 7th answer in the FAQ :) http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/design_choice...
By the way, are there any plans on creating a good Networking library, one that doesn't provide just low-level HTTP support, for putting up for acceptance in the Boost libraries?
Yes, but my approach is to start with the low level building blocks and use them to assemble higher and higher level libraries. Beast is the first step. Next we need a library to check SSL certificates against the operating system root certificate store. Then we need a library to calculate configured proxy settings using operating system calls. And a URI library. With that, you can start to put together a decent HTTP client that supports OAuth. On the server side you need some additional things like a streaming JSON parser, MIME/form decoder, compression codec, and a few other odds and ends. My plan is to develop these pieces as individual libraries and build everything up into the high level solution that you are looking for. I believe the reason that we have not seen these good high level solutions is because no one has taken the time to decompose the problem into standards-worthy solutions. Thanks