2016-04-24 10:14 GMT-03:00 Vinnie Falco
I'm open to collaboration but also cautious.
That's good to know.
From the rest of your reply, I assume Boost.Http isn't ready to be integrated right now.
I wish you could put more details in the documentation, so I can understand Beast better without delving into the code. Maybe I'll bug you more later once Boost.Http advances a little more. And, like Bjorn already stated, nice library. There's a strong need for simple free functions
to send and receive HTTP messages on a socket in as few lines of code as possible. Beast.HTTP achieves this. Example code:
using namespace beast::http; boost::asio::ip::tcp::socket sock(ios); ... request
req({method_t::http_get, "/", 11}); req.headers.replace("Host", "boost.org:80"); req.headers.replace("User-Agent", "Beast.HTTP"); write(sock, req);
You explained your point quite well. Could you please write an example of how do you imagine the ideal server-side API? "Boost.Http currently only provides a server-side API, but the
reviewers felt that a client-side API would be usable to more users."
Beast.HTTP is completely role-agnostic, and works for building clients and servers.
We hope to develop the client-side API after the parser project is finished. The same abstractions should be used too. However, it may be useful to add client-side only useful functions where we can have specialized get or post methods. Bjorn is wrapping libcurl into a Boost-like interface to gain knowledge: https://github.com/breese/trial.http.curl "There was also a recurring request for Boost.Http to be a header-only
library. The HTTP parser currently used is not header-only and that is the main obstacle towards a header-only Boost.Http library."
Agree 100%. Beast.HTTP also uses the NodeJS parser, and that's the only bit of code that is not header only. Thursday I started on a header-only parser, here's what we have so far (please keep in mind, this is a work in progress):
https://github.com/vinniefalco/rippled/blob/my-parser/src/beast/test/http/my...
I wasn't aware of this effort before. 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. 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). It should also be easy to expose iterators using this parser and allow us to reuse all STL algorithms. You can take a look at this parser's proposal at https://gist.github.com/vinipsmaker/4998ccfacb971a0dc1bd . You can see an example of a pull parser at https://github.com/google/pulldown-cmark . -- VinÃcius dos Santos Oliveira https://vinipsmaker.github.io/