Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-03 02:44:56

On 7/2/2017 8:17 PM, Niall Douglas via Boost wrote:
> (note to this reply: on his request, Vinnie and I have replayed an
> offlist conversation we had back onto boost-dev in order to get
> feedback. Hence the tone adopted is a bit weird and I'm talking about
> boost-dev as a third party, which makes no sense if I were writing this
> to here. Be aware I have edited this message somewhat over the original
> as this goes on the public record, it is not identical to the original)
> 
> 
>> I have no desire to enlarge the scope of Beast beyond that which is
>> suitable for standardization.
> 
> I would be absolutely amazed if HTTP hard coded for the Networking TS
> could be standardised.
> 
> There are tons of big C++ users out there who would rightly veto such a
> thing. Qt provides an extensive networking implementation which does not
> work well with ASIO. So does Apple, Google and Microsoft, all of whom
> have substantial proprietary networking implementations, and whose WG21
> reps would veto such a proposal in my opinion.
> 
> If you are aiming for Beast to be standardised, I think you are
> absolutely dead in the water with the current design. I had no idea
> until now that you intended that, and I really think you need to tell
> the Boost peer review that, because I don't think anyone else realises
> that either.

No, this sort of thing is irrelevant. Whether any Boost library would 
like to be part of the C++ standard or not should not come into 
consideration when reviewers look at a library to be added to Boost. In 
reality nearly all Boost authors of libraries probably would like their 
libraries to be added as a C++ standard library, but this has nothing to 
do with the quality of the library itself.

Furthermore, as I follow discussions about Beast, I am pretty sure that 
the library author is not saying that, which is meaningless, but instead 
is saying that he designed his library to be compatible to what the 
Networking group of the C++ standard is considering adding to the C++ 
standard. You are of course free to disagree with that decision, since 
there is nothing inherently sacrosanct on whatever is, or may be, in the 
C++ standard. But that has nothing to do with the saying a library would 
like to be part of the C++ standard, which no technical value whatsoever.

> 
> If they do realise that, they'll very considerably raise the bar to pass
> review like how they treated Outcome and AFIO, both of which were
> advertised to be intended for standards. So I won't mention it, it's up
> to you. But if you want Beast into the C++ standard, you really ought to
> say that's your plan now as an announcement. You'll get a much more
> useful to you review, even if that means a rejection. I found both the
> Outcome and AFIO reviews enormously useful.
> 
>> If you feel that Beast should work with non-Asio I/O models then the
>> venue for that fight is in the LEWG. Beast will track the standard or
>> as close to it as possible. So if you convince the working group there
>> is room in the standard for networking I/O models different from
>> Net-TS, Beast will adopt them as a matter of policy.
> 
> That's not how standards work.
> 
> WG21 had to pick *some* networking implementation. It was getting
> embarrassing for C++ to not have one. But by choosing ASIO, in no
> possible way will that choice be allowed by major C++ users with
> representation on WG21 to damage the existing ecosystem of diverse and
> very popular other networking implementations, most of whom are vastly
> more popular in user count than ASIO is.
> 
>  From what I've been told, there is a fair whack of people on WG21 who
> see ASIO as the interim Networking v1, with a strong expectation that a
> v2 will replace it once they've done iostreams v2 and built out a proper
> general purpose i/o layer for C++. So hard coding HTTP to Networking v1
> would be foolish, it upsets the proprietary vendors many of whom are
> hoping to get their proprietary system into the standard in years to
> come, and it's a waste of work when Networking v2 may happen and you'd
> like your HTTP implementation to work on both. What you'll then see is
> repeated deferment of decision, it'll keep getting kicked down the road
> and it'll never happen.
> 
> But listen, don't take my word for it. I've only been tangentially
> involved in standards for a decade or so, and less with WG21 than other
> WGs. Ask someone like Bjarne, he's got a vision of where i/o in C++
> needs to go next. And I understand that he is not exactly keen on ASIO's
> API design.
> 
> Niall