Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2016-09-23 20:52:25

On Fri, Sep 23, 2016 at 5:25 PM, Vinnie Falco wrote:
> 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?

Not necessarily; I would take away from that only that HTTP is the
area of interest enough to evoke initial discussion. i.e. During the
review, anticipate/prepare for any portion, be it your WebSocket class
template, or even the implementation of types in your detail and impl
namespaces to be scrutinized.

> What would the library be called in Boost? Not Boost.Http. Would it be
> Boost.Beast?

My personal vote would be to have the HTTP functionality under
something named Boost.Http; e.g. Boost.Http.Core.

If WebSockets and Http both live under the same Boost library, which I
believe is your intention, then your current organization of
Boost.<Library>.Http and Boost.<Library>.WebSocket makes a lot of
sense. I'd prefer that <Library> identifier should be something less
abstract than "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?

boost::http::core::message sounds fine if the Boost.Http space will
encompass both your lower level functionality, as well as higher level
utilities. Good to hear about the desire to provide a SOCKS
implementation.

> 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?

Sure.

> 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?

Obstacles for getting a review, certainly not. If you meant that
during review it would be a point raised against acceptance, or
conditional-acceptance, I wouldn't want to make that prediction.
You've already done the right thing by designing the library for
users, not designing the library to pass the Boost formal review
process, so the review will just give you an opportunity to:
- Determine whether there is interest in the library as it is for
inclusion into Boost
- If conditionally, or if not, identify what the community that
participates does want in your library
- Decide whether you feel it is in the best interest of the library to
accommodate those requests (either now, or over time)

> How do I start the formal review process?

1. Get it listed on the Boost review schedule page. Ron will be able
to help you with this.
2. Find a someone from the community (e.g. Boost developers)
interested in managing the review

Then just work with the review manager to schedule the review.

Glen