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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk