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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-03 00:17:55

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

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