Subject: Re: [boost] [asio-users] [http] Formal review of Boost.Http
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-15 08:06:12
On 13 Aug 2015 at 8:58, VinÃcius dos Santos Oliveira wrote:
> First of all, sorry to all members of the list about my unavailability. I
> was planing to write an experimental HTTP 2.0 backend, so I could give more
> confidence about how much I believe this Boost.Http core I present for
> review is the right abstraction.
> Anyway, looks like I took the wrong approach. I should have answered the
> easiest questions first and implement the HTTP 2.0 backend (experimental,
> using existing-library and not Boost-quality) later.
That's a wise move VinÃcius I think.
> > 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'm okay with that.
You may be, but I would worry about your users. Boost users expect
stability and permanence.
> > 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.
> If you want a high level API, you're going to use coroutines. There is
> nothing in the wild so readable as coroutines. Coroutines are **the**
> solution to solve spaghetti code in asynchronous abstractions. Lambdas and
> futures will never be as readable as coroutines. Anyway...
God no. I would see a top level API as being synchronous, so
something like python's urllib3:
r = requests.get('http://www.boost.org')
It may coroutinise but still appear to be synchronous, but that's a
separate moving ball and not one Http can tackle alone.
> The more I think, the more I believe how much such "middle-level" API is
> It's not really like Boost.Http is too low level. It's more like only the
> less polemic building blocks are available now. You'll see the same main
> players in a higher-level abstraction and the main difference is most
> likely that you won't manage the main players yourself.
Think of it as a Boost user. The average Boost user is going to see
Boost.Http and think to themselves, "oh goody I can now write:
r = requests.get('http://www.boost.org')
... in C++ and yay I've just chopped 10,000 lines of buggy hack code
from my codebase."
And that's exactly what I would expect too from a library called
What you're providing isn't that though: it's a set of low level HTTP
related extensions to Boost.ASIO. From my review of your code and
docs, and what you've told me, I think the ideal location for your
library is within ASIO under the asio::http namespace. However,
assuming Chris isn't keen to allow that as a git submodule within
ASIO (he might be, I don't know), I think as a very minimum you need
a name for your library which says it is a set of low level HTTP
related primitives for Boost.ASIO. That name is not Boost.Http for
sure. A later library you might submit could be called Boost.Http,
but it would provide a daft easy API like the above for Python's
In fact, if you can achieve a more appropriate name choice, I'll
change my vote from rejection to a conditional acceptance as you've
done a great job in persuading me from where I was. You've impressed
with me your awareness of the tradeoffs involved in a moving API
environment, and though I severely personally disagree with your
choice of Boost.ASIO over ASIO, I can also see that targeting a more
stable API in the form of Boost.ASIO for now makes sense.
How does that sound?
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk