Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-09-23 14:50:09

On 23 Sep 2016 at 7:58, Vinnie Falco wrote:

> One point brought up during the conference is that Beast does not
> offer sufficient higher level HTTP functionality. This omission is
> intentional. It is my idea to offer the building blocks (serializing
> and deserializing HTTP/1 messages, in synchronous and asynchronous
> flavors, and a universal HTTP message model), upon which other
> developers more knowledgeable than me could build those interfaces.

Time to be mildly harsh.

I'll repeat my main observation made during the Http review:

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++ (it need not be Python Requests specifically, 
just some well established highly regarded high level HTTP API battle 
tested over many years - the key part here is DO NOT try reinventing 
the wheel over well established practice).

We don't care about async, memory copying, performance, use of 
std::string, parsing, use of ASIO, serialisation or any of that other 
detail until somebody gets the bloody top end API implemented and 
stop wasting time on these currently unimportant implementation 
details.

AFTER somebody has implemented a close replica of Requests which is 
fully functional - and very few here would care how it is internally 
implemented so long as the public API design is solid - THEN the 
refinement of implementation can begin.

As I was saying to David Sankel and Roland Bock yesterday when we 
were discussing HTTP and BEAST, I really wouldn't care if you stuck 
O(N^N) complexity loops into your implementation and throw in a 
pointless sleep(500ms) for good measure in an initial implementation. 
*I don't care about the quality of the implementation*. I only care, 
for now, about the solid design of the top level API. Once we have a 
working implementation of that which has passed Boost peer review, 
everything else will follow naturally.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/