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