Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-09-23 16:18:11

On 9/23/16 11:50 AM, Niall Douglas wrote:
> 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).

I'm not understanding this point.  Vinnie just said that it doesn't 
currently offer more than a minimal level of functionality.  Sounds to 
me that you're agreeing with him

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

Again - I'm not getting this.  What are you objecting to?
>
> *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.

Again, I'm not sure what side you're on here.  But I will say that that 
quality of implementation is the single most important thing.  There's 
two schools of thought here

a) Get your library to some advanced stage, post it and ask for feedback 
before you invest a lot of effort in correctness, documentation, tests, 
etc.  The theory is that interested parties will contribute suggestions, 
observations and fixes and help you along.

b) Make a completely finished but minimal library including tests, good 
documentation, examples etc.  Then hope that users try it, are happy 
with what it does, then clamber for more features and enhancements.

c) Finish the whole damn thing

The worst is a) once someone downloads/clones your library and find that 
it's hard to understand, has bugs or in any way frustrates you, they are 
lost to you forever.  They'll never come back.

The best of c) but that's very hard to do

b) Is the best most practical approach and that most likely to lead to 
success.  It's strongly supported by the incubator.

Robert Ramey