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:
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
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?
> 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
-- 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