Re: [boost] [beast] Request for Discussion

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

On Fri, Sep 23, 2016 at 11:50 AM, Niall Douglas
<s_sourceforge_at_[hidden]> 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?

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?

Thanks