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.