On Sun, Apr 24, 2016 at 3:33 PM, VinÃcius dos Santos Oliveira
I wish you could put more details in the documentation, so I can understand Beast better without delving into the code.
Agreed. The HTTP side can definitely use more documentation. Since the announcement I added a new page which explains things step by step: http://vinniefalco.github.io/beast/beast/http/usage.html
like Bjorn already stated, nice library.
Thanks, it is appreciated!
Could you please write an example of how do you imagine the ideal server-side API?
Well, being role-agnostic means the same functions are used by both
clients and servers. The only meaningful difference is that a server
will receive request objects and send response objects instead of the
other way around. The message class template distinguishes requests
and responses using a bool "isRequest" template argument. These
statements each declare a response:
http::message
...it may be useful to add client-side only useful functions where we can have specialized get or post methods.
These definitely sound like useful operations, and they should be available at some interface level. But its not clear that they they are sufficiently general purpose as to merit inclusion in a library that tries to satisfy everyone. No matter how specialized the get or post method there still needs to be a way to package the message up in a first-class type and send or receive it; Beast provides the means to do that.
Thursday I started on a header-only parser,
I wasn't aware of this effort before.
Its a minor effort, likely not worthy of fanfare.
I took a look now that you mentioned. From what I've seen, I assume that this parser has a SAX-like interface where you interact through callbacks.
I'm writing something that functions very similarly in style to the nodejs-http-parser, but updated for C++. The goal here is to eliminate a blemish on Beast, that it is not completely header-only. It inherits the zero-memory / zero-copy design of nodejs-http-parse to retain as much of its performance as possible (although, it does away with architecture-specific branch prediction hints). Some of the design improvements I'm making: * Users derive from the parser base class using CRTP (Curiously Recurring Template Pattern) * Callbacks are optional, detected through SFINAE * Callbacks are made to the derived class * The callbacks are transparent to the compiler (i.e. no function pointers), allowing inlining * No macros or dependence on preprocessor directives * No dependencies except for boost::string_ref; easily reused in other projects * Random HTTP-message generator for fuzzing
The Boost.Http parser that will be developed within this summer will be a pull parser. It has a less intrusive design and can be used to build parser with SAX-like interfaces or DOM-like interfaces. It should be useful enough to also be used as is (i.e. without wrapping in another interface).
Beast doesn't try to offer a universal or flexible parser, it just offers a parser that gets users reading messages right out of the box, and is sufficiently robust and performant as to make it a competitive choice for implementing production-class servers. Beast's HTTP message reading implementation is general purpose, callers can provide their own Parser template argument that meets the type requirements (*), permitting alternate implementation strategies. For example, keeping only the headers you care about. Or using a perfect hash function to decode the field name to an enum. This works hand in hand with customizing the Headers parameter in the message class template argument. (*) planned feature
It should also be easy to expose iterators using this parser and allow us to reuse all STL algorithms.
Since the whole thing is now templated it might be practical to revise the interface to accept a Boost.Range of chars and work with iterators in the fashion you described. That could be the subject of a future improvement.