On 2015-08-15 10:01, Bjorn Reese wrote:
A quick reminder that the formal review ends on Sunday (August 16th.) Oh my, time flies...
Please consider submitting a review where the following questions are answered:
1. Should Boost.Http be accepted into Boost? Please state all conditions for acceptance explicity. I did expect a library that
* offers both client and server side * offers a high level interface that allows me to get started very quickly, without having to worry about the gory details * offers tons of ways to tune, in case I feel the need to do that * supports HTTP/1 through HTTP/2 I got * server side only * the low level interface only * no HTTP/2 * probably lots of tuning options (but see documentation) I can live with not having a client side at the beginning, but if the current library should be accepted, a full review of the client part would be required. Having no HTTP/2 support is a surprise, as I consider boost to be cutting edge. Having no high level interface is a show stopper for me. I won't try to work my way through the details if I need what feels like a hundred lines of boiler plate before even receiving the first byte. And then I would have to care about stuff like: "You should send a 100-continue to ask for the rest of the body if required." If it is required, it is required. Why do I have to check for it myself? The library should take care of that (unless I tell it not to, because I want to do my own magic). Similar with chunking. If I send chunks and I should not, can't the library take care of it by default (i.e. by buffering the data)? Or this: self->socket.async_write_response(200, string_ref("OK"), reply, yield); Admittedly, not horribly much to write, but since I am using an HTTP library, I would have expected convenience functions and enums that make sure I do not mess stuff up (e.g. by sending 404/OK). Reading the documentation did not exactly encourage me to play with the library. Looked to me like I need to know my way around HTTP very, very well to not run into traps all the time. Thus, I admit that I really haven't invested that much time, but as of now, I vote for No, the library should not be included.
2. What is your evaluation of the design?
3. What is your evaluation of the implementation? I haven't really looked into the code.
There was some discussion about the library being C++11 only. I do not see that as a problem for a new library. I can totally understand if a library author these days does not want to spend time in supporting older compilers. While this will certainly limit the number of users in the beginning, I believe that it is the right strategy in the long run (and it saves time and nerves of the author).
4. What is your evaluation of the documentation?
The last time I did something with Boost.Asio was about five years ago. That might be why I find it hard to read, but I doubt it. Maybe there isn't much to say, since everything is so low level that it is basically Boost.Asio, but the long reference list makes this doubtful as well. It is a tutorial with basically one example. The front page has hints to a lightweight HTTP Server and a file server (er, what?), but I did not find any documentation for those. I cannot really tell what else is all missing, but the documentation seems to be rather incomplete.
5. What is your evaluation of the potential usefulness of the library?
Potentially very useful. It just does not seem to be there yet.
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?
About an hour of reading, then about 2 hours of going back and forth between this mail and the documentation. I would really like to see an HTTP library for Boost. I just pushed a library for text templates (e.g. HTML) to github. I would like to combine that with an HTTP server for some projects. It could very well be based on Boost.HTTP eventually. But I do not think it is ready yet. More convenience for the casual users and certainly more documentation (and probably a different tutorial) for such users will certainly help a lot. Since I did no dig very deep, I can't tell if that would be sufficient, though. Best, Roland