Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-09-23 17:11:10

On 09/23/16 23:22, Vinnie Falco wrote:
>
> Just look at that awesome list of features. The Python Requests
> library is something we should hold up as a model of how we want a
> full-featured HTTP client library to look and act.
>
> Unfortunately, even a reduced subset of these features goes far beyond
> my resources to implement. I also do not feel confident in my
> knowledge of the domain or my abilities to provide a robust C++
> interface for all of this.
>
> I think that what Niall has done, probably inadvertently, is to
> demonstrate just how broken the Boost review process has become. We
> have Beast, which provides a great implementation of the low level
> HTTP operations (read and write a message, provide a message model). I
> am sure that someone or some group with expert knowledge in creating
> robust HTTP clients could come along and build the C++ equivalent of
> Python Requests on top of Beast. It should not be controversial when I
> say that Beast offers useful functionality today.
>
> And yet, there are strong opinions that Beast as a low level HTTP
> building block is insufficient to be considered as part of a general
> purpose library Boost. Once again I must ask, if Boost.Asio were
> proposed today would it receive the same critique? Would an absence of
> FTP and HTTP implementations make Christopher Kohlhoff's Asio library
> get rejected in a formal review?
>
> The modern consensus is that C++ libraries need to become more focused
> and smaller, performing a single task and doing it really well. And
> that is exactly the design principle of Beast - model the HTTP
> message, serialize and deserialize HTTP messages synchronously or
> asynchronously. This might not satisfy the majority of use cases but
> it gives interested parties something they can work with. Who are the
> interested parties? Anyone who wants to write a generic web server. Or
> a full featured HTTP client. You want those features right, and you
> want them in Boost? Then why would we reject a library that offers the
> primitives for other people to create such high level implementations?

Please, don't let Niall's message discourage you from proceeding with 
your submission (or underestimate the positive effect of community 
review). I'm sure some people, myself included, think that designing 
HTTP/FTP/whatever protocol from bottom up is a totally reasonable approach.

It may be difficult during the review to show the immediate practical 
gain from a lower layer component, but if you can demonstrate how a 
higher level layer could benefit from your library, you should be fine. 
If you can show that porting a library like Boost.HTTP to Beast is 
possible and beneficial, that would be even better. I hope you and 
Vinicius Oliveira will be able to talk and cooperate on this matter.