Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2016-09-23 17:25:25

On Fri, Sep 23, 2016 at 1:46 PM, Glen Fernandes
<glen.fernandes_at_[hidden]> wrote:
> ...
> 1. You have a decent library, both in terms of design and implementation.
> Like Paul, I suggest you put it up for review whenever you feel comfortable.

Thank you for the kind words.

> 2. You should keep the focus in your discussions on your library and not on
> the Boost review process.

That's good advice. I will table the issue of whether Beast should
offer more high level operations such as a full featured HTTP client
or general purpose asynchronous server.

> [1] If you require more discussion about the interface to reach that level
> of comfort, you've already taken the necessary steps by soliciting feedback
> here.

Yes there are a few points that should be addressed:

So far there has been a lot of talk of HTTP and not a word about
WebSocket. Does this mean that Beast's WebSocket interface is
non-controversial?

What about the stuff in here:
https://github.com/vinniefalco/Beast/tree/master/include/beast/core

These currently are official interfaces, and I would like to keep them
that way. In fact, I think some of them should be part of the
Networking TS (buffer_cat in particular). Is this a problem? What
namespace would they go into? e.g. boost::buffer_cat?
boost::beast::buffer_cat? boost::asio::buffer_cat (that would probably
be the best choice but it injects names into someone else's namespace)

What would the library be called in Boost? Not Boost.Http. Would it be
Boost.Beast? I do plan on adding more to this library such as SOCKS
proxy support (that would be a new protocol). Would we just rename
beast to boost, i.e. boost::http::async_read, boost::http::message?
What happens if someone else puts together a full feature HTTP client
in a new proposed lbrary, what would they call it?
boost::http::client?

HTTP/2 support came up as a blocker in last years reviews. Beast
design does take HTTP/2 into account. Objects which are HTTP/1 only
are clearly marked (e.g. beast::http::message_v1) and HTTP/1 specific
algorithms are overloaded on those specific types. Are these points
obstacles for review?

How do I start the formal review process?