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/