On Sun, Jul 2, 2017 at 5:00 PM, Niall Douglas via Boost
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
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
(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
