Boost logo

Boost :

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:

import requests
r = requests.get('')

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
> underestimated.
> [snip]
> 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:

import requests
r = requests.get('')

... 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at