Re: [boost] [asio-users] [http] Formal review of Boost.Http

Subject: Re: [boost] [asio-users] [http] Formal review of Boost.Http
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-11 13:35:38

On 8 Aug 2015 at 13:48, Vinícius dos Santos Oliveira wrote:

> But the design
> wouldn't change noticeably and that's why I believe Boost.Http is ready for
> review. Some of the requirements you're complaining about aren't Boost
> requirements. Boost.Http isn't perfect now (and it'll take maybe a few
> years before I exhaust my plans for improvements), but it has a strong core
> that is already useful by itself. Lots of Boost libraries continued to
> improve with time. It's not like you only do bugfixing after a library is
> accepted.

All of this is true. And I am mindful I am complaining about a design 
choice which is specifically that you are targeting Boost before 
WG21.

However a Boost library is about intent and purpose and philosophy as 
well as technical architecture and implementation. I personally 
believe "Boost-ness" can mean a library should not be part of Boost 
which is self-contradictory I know.

I appreciate that cleaving more closely to the Networking TS instead 
of Boost.ASIO may seem like an internal implementation detail, not a 
design detail. But it ticks the intent and purpose and philosophy 
boxes for me and right now you're not ticking them. Plus, as I 
mentioned, you get "free" Boost compatibility via the ASIO to 
Boost.ASIO conversion scripts.

Where I'm really at is I think if Http is accepted you're going to 
either have to ditch it and reimplement atop the Networking TS as 
Chris folds the substantial changes WG21 will force onto ASIO into 
Boost.ASIO, or end up refactoring Http to cleave more closely to the 
Networking TS anyway.

I am therefore of the position it's more efficient to skip that and 
just cleave right now to the Networking TS.

> The buck always stops with the top most layer, not internally used
> > third party libraries.
> >
> > You NEED to fuzz test untrusted inputs when parsing HTTP. For all you
> > know, your STL implementation could be the thing with the overflow
> > bug, or the way in which you use it.
> >
> 
> I opened an issue, so I won't forget about it:
> https://github.com/BoostGSoC14/boost.http/issues/12

Thanks for that.

> > It could be this queue socket concept of yours is exactly what I 
just
> > proposed as two completion handler and reactor layers. In either
> > case, I don't think queue sockets should be a concept, I think they
> > need to be the core of your library's user facing API.
> >
> 
> And then you aren't following C++ rule number #1 anymore: You only pay for
> what you use. That's why Asio itself doesn't solve this problem for you.
> You can use boost::http::basic_socket<queue_socket> if you need to work
> around Asio composed operations at this level. All customization points are
> there for anyone.

I am finding myself unconvinced by your arguments here. What stands 
in the way of a two layer API design? Bottom layer is racy but lowest 
latency. Top layer is not racy, but adds some latency.

I think for the majority of HTTP users they just want it to work 
without surprises to a high default performance level. If you look at 
the history of the HTTP library support in Python you'll see what I 
mean - firstly, it's surprisingly easy to get a HTTP library API 
design wrong, even in a v2 refactor. And secondly that people need 
both a stupid-simple API and a more bare metal API *simultaneously* 
with HTTP, and therein lies the design gotcha.

Niall

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