Hi Vinnie!
On Fri, Sep 23, 2016 at 10:58 AM, Vinnie Falco
Beast provides low level HTTP and WebSocket interfaces built on Boost.Asio, the project is here: https://github.com/vinniefalco/Beast The plan is to solicit feedback from the Boost community before submitting a request for a formal review.
One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. The requestor informed me that this functionality did not need to provide every possible feature or handle every use case. It just needed to handle the common use-cases.
For the record, I am against this higher level functionality for a number of reasons. Despite my objection I have started work on these features anyway. Here are the beginnings of a HTTP client: https://github.com/vinniefalco/Beast/blob/88b485df7e6216282842f40cf99cc7 5dee1b82d4/test/http/get.cpp#L123
Here is some work on a generic server: https://github.com/vinniefalco/Beast/blob/server/extras/beast/http/async_ server.hpp#L84
Your investigation into creating a higher level interface, despite your own reluctance to do so, is very much appreciated. I have a few ideas wrt. what a good higher level interface would look like building off your work. First, I think that the io_service object should not be hidden with a higher-level interface. Asynchronous applications, once the Networking TS becomes available, are generally going to start with the creation of an io_service (executor), followed by the creation of some objects (or calling of functions) which use it, and then complete with a 'ioService.run()' call. Folks who want to do something more sophisticated with a thread pool will have facilities to do so, but this will be the "Hello World" for asynchronous applications. Related to this, I don't think a synchronous interface is necessary. The 'get' function should take in a URL and a callback which has 'error_code' and 'response' parameters. The callback would have the ability to query the response's headers and body (as a string). Streaming the result of a get, I would say, is out-of-scope for the high level interface. A slightly lower-level interface (which may be good enough to replace a special 'get' function) would take in a URL and a requeststd::string. We could include some helpers, like 'buildSimpleGetRequest', that make this easy to use for common scenarios where users don't want to mess around with setting 'User-Agent' headers and such. I'd be happy to work with you on creating a proposed higher level interface that I think would stand a chance at WG21. It may improve consensus for the Boost review, but if it has the opposite effect we could just rip it out. What do you think? -- David Sankel