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