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/