Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-09-23 18:51:20

On 2016-09-24 04:50, Niall Douglas wrote:
> ...
> Time to be mildly harsh.
> ...
> ... 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.
> 
> ... 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 might have expressed his view in a somewhat extreme and 
confronting way but I have to certainly agree with his main point... 
Most likely not in as blunt as Nial made it sound manner but 
nevertheless.

 From my experience Boost reviews indeed often put the cart before the 
horse and get into fierce irreconcilable fights and ultimatums over 
implementation minutia while totally losing sight or even ignoring the 
design and API -- the two fundamental components essential for lib 
acceptance and longevity. The design allows the lib to evolve and grow; 
and the API... well, it's obvious.

Indeed, other posters indicated that that approach taken to the extreme 
may lead to inefficient implementation, etc. However, such criticism can 
be applied to probably anything. The "extreme" argument appears to be a 
simple/quick/dirty trick to misrepresent and then to discredit an 
idea... any idea.

So, nobody is (or should be) expecting a complete, fully working, fully 
tested, exhaustively documented proposal on a plate. However, that is 
where the wisdom and experience (IMO) of the Boost community must come 
in -- to see the potential of a proposal, to see if the proposal has the 
right building blocks in the right places and has the room to grow in 
the right direction, i.e. that the proposal shows the right design (as, 
I think, Nial tried to convey) to eventually grow and to satisfy user 
expectations. Indeed, such an evaluation is hard. It is so much more 
"fun" to behave like a spoiled child -- I want the proposal to do X for 
me, I do not like/accept how Y is implemented/called. IMO such a 
reception, attitude and expectations are what drives people away from 
contributing to or participating in Boost. IMO in that regard the 
experience of Boost.Convert was quite positive when we somehow managed 
to stay focused on the design (or so I perceived), the proposal was 
accepted in principle and then a group of enthusiasts made sure the 
proposal addressed criticism, implemented/accommodated (or had room for) 
the requested functionality.

Now back to the actual HTTP-lib proposal. I am merely a user. However, I 
do want very much such a functionality in Boost. If Boosters more 
knowledgeable in the field might get together, evaluate the proposal in 
a realistic and mature manner and, ultimately, manage to plant a seed in 
Boost from which a good Boost HTTP lib. might start growing, that be 
delightful. Again, let's avoid "I want a full-grown tree or nothing". 
Let's evaluate (and accept) if that's a good seed that something good 
might grow from... and make sure it does...

Or alternatively we might try to realistically evaluate the situation 
and, maybe, to accept that Boost is somewhat late to the HTTP "party" 
and not to go down that HTTP road due to existing, say, Poco HTTP 
library.