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-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('http://www.boost.org')
print(r.json())

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('http://www.boost.org')
print(r.json())

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

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

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?

Niall

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