Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!

Subject: Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-10-04 23:18:31

> How does the community feel about:
> 
> * Boost.Buffers as a solution to accessing buffer concepts without Asio?
> 
> * Boost.Buffers offering Beast's buffer sequence adapters and dynamic buffers?

I reiterate from my Beast review that the best design for these above is
to use:

* span<T>

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0122r5.pdf

* Ranges TS

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4685.pdf

Both of these can integrate with the Networking TS, but not the other
way round due to ASIO's legacy design.

You chose, against my advice, to base Beast on the outdated and hard
coded buffer sequence design in ASIO. It was not a showstopper for Beast
because Beast was so closely tied into ASIO, so I recommended acceptance
for Beast despite this design choice.

But for a standalone library, things are different. I would advise
strongly against accepting a Boost.Buffers library unless it is based on
span<T> and Ranges and is forward looking into C++ 20 design patterns,
not backwards at C++ 98 era design patterns like ASIO's buffer sequences.

Regarding HTTPKit etc, I haven't looked into it much, but if I remember
I had some issues with your implementation and design there too
specifically the lack of use of zero copy views. Again, as part of Beast
wholly dependent on ASIO and thus limited by ASIO's limits, that's
acceptable. As a standalone library where a much wider use case applies,
I think I would need to set a much higher bar in any review. But I
haven't looked into it, you may have completely changed the design and
implementation since I last looked.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/