Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-12 15:04:11

2016-09-23 22:22 GMT+02:00 Vinnie Falco <vinnie.falco_at_[hidden]>:

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

Hi Vinnie,
I am not well familiar with details of http, and I have not even read all
the responses to this thread, so what I say may not fully apply, but...

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

I believe you when you say that the Python library is amazing.

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

That's ok. You do not have to do all of this. It does not have to be one
man's, one-time effort.

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

Exactly. If I ever get to write some of these features, I would like to
have your low-level components, tested and ready.

I am apparently missing something. You are saying as though Boost community
were already against your low-level design. To me this is the correct
approach: start with building block, let someone else write the high level
API. I did not record much objections to this approach. Some potential
users might be disappointed they do not get more, but this does not imply
they are against your http building blocks.

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

Really? Can anybody confirm that they strongly object to having a well
designed http building blocks library in Boost?

Maybe this is just about the name? Maybe if this was called "Http building
blocks", it would get a consensus?

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

To me both ASIO and having a low-level http is fine. In fact, I had
problems using Boost.HTTP because it is so coupled with ASIO. In my project
we are using a custom asynchronous task framework, and I would really
appreciate something that does not impose on me any particular framework or
programming model.

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

I agree with you. I just cannot see with whom you are arguing. You need
low-level libraries in order to build higher-level libraries. Is anyone
questioning this?

Does anyone think that accepting Http building blocks library into Boost
prevents adding a Python-like library in the future?

Regards,
&rzej;