On Sun, Jun 25, 2017 at 2:02 PM, Artyom Beilis via Boost
It may seems like it can be in some competition with Beast but I don't see it this way as Beast is too low level library that does not addresses typical problems of developers needing Web API/Site running using C++.
Beast is not a competitor to CppCMS, as the former is a simple protocol layering on top of Asio while the latter is a Web Development Framework. Beast does not intend to be a web framework now or ever.
I understand that you work on base of Boost.Asio - which itself has unacceptable compilation times but having for web application development may be serious deal breaker for big projects.
I'll note that the very first complaint during the Boost.Http review (2015) was that the library is not header-only. If Asio compilation times are unacceptable then you will find Beast compilation times unacceptable as well, since Beast is very much tied to Boost.Asio as a base layer.
I see that almost every object there is some kind of template object.
It almost mimics the API of Boost.Asio which on its way has its limitations.
Very astute of you to notice! In fact, an overarching design goal of Beast is "emulate Asio in all possible ways." If you feel that Boost.Asio has limitations, you find similar or identical limitations in Beast. Conversely, those who feel that Boost.Asio has tremendous flexibility and expressive power, will also find similar in Beast. I find myself in the latter camp, but your mileage may vary.
I have strong feeling that lots of stuff can actually be done using classic OOP.
There is no question that it would be possible to create non-template classes for every conceivable choice of template parameters but I'm not sure that's a productive use of time and while it might satisfy most users to have explicit instantiations for boost::asio::ip::tcp::socket and boost::asio::ssl::streamboost::asio::ip::tcp::socket it is certain to leave at least a few people in the lurch. For example, "that guy" who wants to write an AsyncStream wrapper for his libuv socket so it can work with Beast.
Can I implement same server code for both SSL and non SSL HTTP protocol without use of templates in the class itself?
If you can do it with Asio then you can do it with Beast. Typically this is done with type erasure for the main template parameters which are 1. the stream object, 2. the buffer sequence, and 3. the completion handler. You can do the same with Beast, except that you will also need to make a commitment to one type for requests and one type for responses. This makes some of Beast's cool template driven features not work but it seems like you're okay with that tradeoff.
Who are the potential users of the library?
Beast is primarily aimed at library writers, although it frequently satisfies high level application developers even with its verbose interfaces since the alternatives are objectively worse.
If I need to send a simple http request to server it does not seem to do simple enough job (see your FAQ) so I'll probably be better with feature rich libcurl.
Beast is definitely not a replacement for libcurl, and likely will never be. Libcurl is a full featured HTTP client, while Beast is merely an HTTP protocol layering on top of TCP/IP using Boost.Asio's asynchronous model. However, someone eventually is going to make a better libcurl by writing it on top of Beast, and then we'll see some nice things like C++ native interfaces, with lambdas, type safety, perhaps template arugments defining HTTP client specific concepts such as BasicAuthenticator or MultiPartConsumer (I made those up but the names allude to their usage). Most importantly, someone who writes a C++ libcurl on top of Beast will be able to present complete, type-safe, fully-intact message objects to the caller when asked, and then that message object can be passed to other libraries or algorithms built with Beast. There's a network effect when you have a good set of vocabulary types and algorithms, and Beast aims to provide that for HTTP (and WebSocket!). Just like how the standard library gives us a common voice with which to explain solutions to general computer science problems, Beast provides the pieces for building solutions to HTTP and networking problems. My goal is to guide Beast through Boost acceptance, widespread adoption, and then a proposal for the C++ Standard Library.
If I need to implement complex web server/service I don't have cookies, sessions, forms, html? ... If I need to implement RESTful API do I have all stuff like URL mapping of different paths to callbacks, protocol abstraction http/https (basic stuff - I don't see it there correct me if I wrong)
Everything you described is out of scope for Beast. I'm hopeful that the existence of Beast will inspire programmers to create new higher level libraries to solve the problems you listed in a composable and interoperable way.
Is it for web server developers?
You can build a web server with Beast. But as you pointed out, you will have to either write for yourself or find in other libraries some important pieces like a URI parser, cookies, authentication, codecs for the various Content-Encoding, a multi-part/mime library, and so on and so forth. Obviously we would all be happy if these things existed already with perfect C++ friendly interfaces and with composability and interoperability in mind but they don't. Beast is the first down payment on that dream.
Maybe I'd be happier with simple HTTP protocol parser that I can integrate to any socket API?
And you can do that with Beast, the beast::http::basic_parser is designed for users to derive from if they want to take advantage of the parser implementation. You can derive your own parser and feed the buffers from wherever you want. Or if you like Beast's message model (I happen to think its rather well designed but that's just my opinion) you can use the beast::http::parser by feeding in buffers to produce messages which you can do whatever you want with. This is covered in the documentation, with examples: http://vinniefalco.github.io/beast/beast/using_http/buffer_oriented_parsing.... If you want to serialize HTTP messages to buffers without using Asio and sockets you can do that too, using beast::http::serializer, also covered in the documentation, with examples: http://vinniefalco.github.io/beast/beast/using_http/buffer_oriented_serializ...
Can you please give more accurate description of who is this library intended for?
Its a fair question although I thought the Introduction in the documentation gave a pretty good idea. Its sort of a hard question to answer because really we have never seen a library like this before which is so low level so I think people just don't know what to think of it especially when they start comparing it to other libraries or applications whose descriptions include the word "HTTP" The library is intended for anyone who wants to build something resembling a high level library that exists today, such as Boost.Http, cpprestsdk, cppnetlib, CppCMS, or any of those libraries which implement either an HTTP client or an HTTP server. Instead of reinventing the HTTP protocol code from scratch Beast gives you a running start. It takes care of all the boring details of reading and writing HTTP messages so that you can write your library at a higher level. Any library that is refactored to use Beast will immediately see benefits. It will result in less code in the target library. That library's interfaces will become more composable. You can take message objects produced by one library written with Beast and pass them into algorithms which take message objects that reside in other libraries written with Beast. So to answer your question, Beast is aimed at anyone who is writing software that wants to speak the HTTP (or WebSocket!) protocols using Boost.Asio and eventually the Networking-TS (http://cplusplus.github.io/networking-ts/draft.pdf), which is a polished version of Boost.Asio that will certainly become part of the C++ standard library. I will conclude by saying that eventually, only networking libraries which are coded against Boost.Asio, the Networking-TS, or ultimately the C++ Standard Library version on or after which the Networking-TS has been integrated, can possibly be taken seriously. After all, who would want to use a library that doesn't use the "standard" implementation of networking?