On Sun, Jul 2, 2017 at 5:00 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
So free your library of the ASIO dependency.
1. Beast stream operations are built for Boost.Asio. 2. Beast's dynamic buffers and buffer adapters are built for <boost/asio/buffer.hpp> This is not going to change. When I port Beast to Net-TS, I will make similar statements: 1. Beast stream operations are built for Net-TS 2. Beast's dynamic buffers and buffer adapters are built for <experimental/network/buffers> (or whatever the header is called) I have no desire to enlarge the scope of Beast beyond that which is suitable for standardization. Like it or not, Boost.Asio is the closest we have to something standard, and soon it will be Net-TS which is practically identical to Asio except for cosmetic difference in buffer types. 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. If you want to fork Beast and show me how its done you have my blessing. If your fork became popular I would definitely reconsider.
...your justifications of design choice to me, and persuasion that your choices are not showstoppers, are what gets a library accepted.
I can't imagine any argument more persuasive than "it tracks standards."
I think your library should...Do one thing really well
On this we can agree. That "one thing" is "HTTP operations on Boost.Asio stream concepts." ...and WebSockets too! Why do they neglect the websockets? Its like the kid who always gets picked last for the team at P.E. Thanks