Re: [boost] [beast] Request for Discussion

On 9/23/2016 4:22 PM, Vinnie Falco wrote:

On Fri, Sep 23, 2016 at 11:50 AM, Niall Douglas wrote: ]> Almost everyone here and in the wider C++ community wants somebody to

...

take the HTTP client API from the Python Requests module (http://docs.python-requests.org/en/master/) and very closely replicate it in C++

Hello! I just had a look at this Requests library and it is AMAZING! C++ most definitely needs something like this! Look at these features it has:

International Domains and URLs Keep-Alive & Connection Pooling Sessions with Cookie Persistence Browser-style SSL Verification Basic/Digest Authentication Elegant Key/Value Cookies Automatic Decompression Automatic Content Decoding Unicode Response Bodies Multipart File Uploads HTTP(S) Proxy Support Connection Timeouts Streaming Downloads .netrc Support Chunked Requests Thread-safety Custom Body Content Workflow Streaming Uploads POST Multiple Multipart-Encoded Files Event Hooks Custom Authentication Streaming Requests SOCKS proxies Link Headers Transport Adapters

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?

I really object to your characterization of "how broken the Boost review process has become". There are numerous Boost libraries which serve as building blocks for higher level libraries and these low-level libraries are just as important for Boost as a higher-level library which might appeal more to end-users in application development.

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?

We don't reject such a library if we find it useful as a low-level library. Niall's opinion about your library is his own. Don't push that opinion on other Boost developers who may feel differently.