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

Subject: Re: [boost] [Boost-announce] [http] Formal review of Boost.Http
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-16 14:10:00

On 7 Aug 2015 at 9:08, Bjorn Reese wrote:

> Please answer the following questions:
> 
> 1. Should Boost.Http be accepted into Boost? Please state all
>    conditions for acceptance explicity.

Yes, with these conditions:

1. It should not be called Boost.Http. Users will expect a high-level 
*client* API in a library called Boost.Http. I'd suggest:

Boost.AsyncHttpServer
Boost.ASIOHttpServer
Boost.HttpServer

2. I think a client HTTP library is a lot more useful to Boost users 
than a server HTTP library. I think it needs a client HTTP library 
before acceptance. I would even suggest you drop the server library 
in favour of the client library - far more people need and want a 
client library over a server library.

3. It needs HTTP 2.0 support.

4. It needs to be socket input fuzz tested on a weekly or more basis.

5. The documentation needs a very great deal of additional work. See 
below.

6. That if conditionally accepted, the library must reenter the peer 
review queue and undergo a second full community review.

The latter condition could be interpreted as me recommending 
rejection of Http at this point. I wouldn't go as far as that - I 
like the library, I like the design, and I think it could be a great 
addition to Boost in the future.

> 2. What is your evaluation of the design?

Unlike some of the other reviewers, I'm relatively fond of the design 
given it's a HTTP server API not a client API. I would personally 
speaking say it involves too many publicly exposed moving parts for 
my own taste. I really don't want to know about the moving parts - I 
just want to serve some HTTP in less than 50 lines of code. I don't 
care about performance until after I am serving some HTTP, and I 
don't want to think about internals or specifics or even async until 
I benchmark a performance problem.

If I were designing something like a HTTP client library, I 
personally would start with a C++ edition of the Python Requests 
library API (http://www.python-requests.org/en/latest/api/) which 
I've enjoyed using in Python and go from there.

> 3. What is your evaluation of the implementation?

The quality of implementation is pretty high. I felt a lot more work 
needed to be done on testing.

> 4. What is your evaluation of the documentation?

The documentation needs a very great deal of additional work. 
Particularly regarding the tutorial and quickstart. Right now it's 
nowhere close to Boost ready.

> 5. What is your evaluation of the potential usefulness of the library?

I'm not convinced that a HTTP server only library is as useful to as 
many as a HTTP client library.

I think a HTTP client library with a high level API would be very 
warmly received at Boost. Even better if it had good performance and 
internal layers which could be unpicked for custom behaviour, but to 
be honest neither of those is necessary: all 95% of users want is to 
fetch a HTTP resource and post form content. Only a tiny minority are 
interested in serving HTTP.

For that tiny minority interested in serving HTTP, I am unconvinced 
they would consider the steep learning curve imposed by proposed 
Boost.Http as worth it when compared to writing some temporary hack 
code which implements a quick and dirty HTTP server on ASIO. The time 
spent learning proposed Http I reckon is about the same as writing a 
quick and dirty hack, and the latter is much more fun.

> 6. Did you try to use the library? With what compiler? Did you have
>    any problems?

No.

> 7. How much effort did you put into your evaluation? A glance? A quick
>    reading? In-depth study?

I have been following the library since its inception during GSoC.

> 8. Are you knowledgeable about the problem domain?

Relatively knowledgeable. I have written a hacky quick HTTP server in 
ASIO before.

Niall

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