2015-08-11 17:26 GMT-03:00 Rodrigo Madera
[...]
Many of the Rodrigo Madera's concerns were addressed by the design choices chapter. I'm glad this chapter proved to be useful, so I don't need to repeat myself and users can lose their doubts without even leaving the Boost.Http documentation. - Maybe it should be (Boost.)Asio.Extensions?
Boost.HTTP is an extension to Boost.ASIO (and hopefully for non-Boost ASIO as well in the near future). Why not create a Boost.AsioProtocols (or Boost. AsioExtensions, whatever) and go around creating several libraries for it?
In the future we might have other protocols on top of ASIO. Boost.FTP, Boost.STMP, Boost.Torrent, etc. They could all go into a protocol extension library, since it's basically message parsing on top of Boost.ASIO.
What do you guys think about this?
Boost.Http is done from the very beginning to allow alternative backends (like I stated on my reply to Niall just a few minutes ago, with much more points tackled). Some backends might not even do network or need Asio (shared memory among process or other means). This feature is important for HTTP applications. OTOH, Boost.Http is fully async and uses Asio abstraction to do asynchronous code. I've already played with several asynchronous frameworks that use different approaches (Qt, Node.js, futures...) and I'm very impressed by Asio proposal. Boost.Http will always depend on Boost.Asio to abstract its asynchronous nature. Anyway, to not delay my opinion further. It's not that I'm very against putting Boost.Http into Asio.Extensions or alike. I'm against putting Boost.Http into a mix of network protocol libraries like FTP, SMTP and others. The reason I'm against is because it may trick the user to think that this is (1) merely a protocol implementation and (2) there will be network activity when Boost.Http doesn't even need network activity (e.g. shared memory based backends). - High-level Usage
I was surprised to see the low level of Boost.HTTP's API. At first I disliked it, but then it seemed natural for the Boost.ASIO mindset. This makes me believe even more firmly in a possible Boost.Asio extension model instead of standalone library.
However, for me (and I bet several users) reading the library name "Boost.HTTP" would seem to be a higher level API. Instead, this looks as Boost.ASIO.HTTP. Which brings me back to preffer Boost.AsioExtensions.
Maybe a higher level abstraction for simple use cases? Something like resource routing and interception capabilities, maybe.
I'm not yet sure I wish to write HTTP code this low level.
cpp-netlib, pion and many other provide request routers and server abstractions. They usually couple all abstractions together and use a design like: - There is the server+request-router+handler+thread-pool+... - Request factory, which the user will extend and pass to the above inflated abstraction. Even if the request object is decoupled from the server object, allowing you to implement your own server with your own needs, support for alternative HTTP backends would be left out, which is wrong. The message-oriented abstraction in Boost.Http solves this problem. Node.js takes a different approach on the request router matter by providing none. This is awesome because then you can choose whatever style you prefer. You can register a tree of handlers to implement a ReST service. But then, maybe a tree-based request router is not appropriate to your application and you want a middleware-like request router. And then there are the rules the request router is going to use (resource/path/uri requested, authentication headers, arbitrary user-provided predicate). The request router itself might be seen as a handler and you might want to nest request routers. The thing here is that I'm very ambitious about this project and I estimate I'd take as long as the already spent time just to deliver the request router. I want to be sure that I'm providing the best request router possible to write. Something that could go into the C++ standard and nobody would fear to be deprecated in the future. A big challenge to the request router is that it can become rather inefficient if I put customization points everywhere. And if I think about performance, I remember that most of the request routers I saw allow you to change the rules at runtime when this feature is rarely needed. Maybe some TMP magic can help here. - Benchmarks
How does Boost.HTTP perform against, lets say, Boost.ASIO's several HTTP server examples?
Should I really use Boost.HTTP instead of some simple as possible layers typical of embedded servers? What's the cost?
Graphs would be most welcome. Users want to be convinced that they will get an edge by choosing Boost.HTTP.
I'd suggest to focus on correctness. It's very tricky to get a correct implementation that will portably work among several little know implementations. You just should not use an unmaintained copy & paste solution. - HTTP 2.0
Will it be added in Boost.HTTP?
Will it be a separate library (Boost.HTTP2)?
I'll try to provide a proof-of-concept tonight. It won't be Boost quality and I think I'll use nghttp2. But should be useful to help the job of the reviewers. - Haste to Review
As it is right now I see that http is urging haste to be boost under the argument that "other things are not requirements". I would suggest seeing this rather as a craftsman art job rather than a legally conforming implementation on what is expected and "required" for boostification.
Boost was never about requirements. It's about C++ cleverness. The good kind. It's about making good, outstanding libraries with the maximum quality possible. Not about meeting minimums. I'd choose any Boost library over any other in the market 9 out of 10 times.
The library is very near completion. It provides a layer that most applications will use to communicate. I myself am needing it right now to substitute my hand made provisions. I really want Boost.HTTP, but it needs more work.
I'm pretty sure Vinicius will deal with these little items in no time. I know him from our online Brazilian C++ users group, and I know it won't be much of a challenge for him. He's really good and it's not his first HTTP library. Win/win situtation.
I'm sorry if I left you guys under this impression. The first answer we got from the review was Niall's reply, focusing on features that would not even go on the Boost code or change the API design. This fact might have contributed to this view. These features aren't required for Boost and it'd be very weird to have a library rejected because these requirements. Also, there are features not implemented now that deserve further explanation to remove the impression that you guys got. This project can accumulate a lot of polemic decisions easily. I worked for quite awhile already and managed to finish the core of the library (and some extra features already like the possibly most amazing file server API that nobody here acknowledged/noticed ;-) ). I want this core into Boost as a confirmation that the design is right so far. And here I'm defending my design. And maybe the design is right as most (if not all) complaints are unrelated to the already proposed design. A high-level API will just manage the main players already exposed to remove the need for such amount of boilerplate code. However, I should state that I'm grateful for all the feedback this review is generating. Lots of points/hints on improvements to the library. And aren't obvious points, but things that make me think that a great deal of time was spent on the review. [1] http://nghttp2.org/ -- VinÃcius dos Santos Oliveira https://about.me/vinipsmaker