Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: David Sankel (camior_at_[hidden])
Date: 2016-09-28 20:39:40

Hi Vinnie!

On Fri, Sep 23, 2016 at 10:58 AM, Vinnie Falco <vinnie.falco_at_[hidden]>
wrote:

> 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 request<std::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