Hello community, I'm not done playing with Boost.HTTP yet to give deeper usage insight, but I want to throw in some things I have already noticed that really concern me. I do agree that, from a logical point of view, Vinicius is right in saying that "It's not against the rules" to do something with a rather lower bar than the same thing done right, I still believe it's against Boost's stablished quality. Allow me to explain: - The library should be header only While (strictly speaking) it's not a Boost requirement, there is no strong reason here to require a compiled library. Since Boost.ASIO is header only, and since Boost.HTTP is technically an extension of Boost.ASIO, it should model it and be completely header only. According to the documentation page [1], the library isn't header-only because it uses a borrowed C parser, because it creates it's own error codes, and pretty much just those two. The first one could be solved using Boost.Spirit (which is on the Roadmap). The error categories, I would just ask this: How did ASIO solve it? I'm not against Boost libraries depending on one another if there is a clear advantage over it, so Boost.Spirit would be a great option for parsing. I never did more than the basic HTTP header parsing, so simple regex works great for my current use cases. I don't think parsing HTTP would be that much of a trouble using Spirit. - The library doesn't really need C++11 Boost.HTTP only uses C++11 for the convenience of enum classes and lambdas [2]. This by no means is justified requirement of C++11 functionality in a Boost Library, except for Proof of Concept work and prototyping. Once the library is sound, it should go to C++03 or even C++98 if at all possible. Now let me be clear: I know some will just jump on the "Boost should now push the compiler boundaries" bandwagon, but that's not how I remember Boost to be. I understand the recently added Boost.Hana is groundbreaking and all, but IMHO these kind of experimental libraries shouldn't be the norm. I was tempted to vote No to Hana approval (despite it's greatness) just because of that. To me, Boost is a complementary set of C++ libraries that went a far way into giving full compiler support for even the most stubborn (and archaic) of compilers. Even if it meant implementing several workarounds. I can relate to the usefulness of such support, having worked at a Fortune 500 with an ancient environment that supported (and I believe still does) millions of customers. Boost supported it thanks to countless hours of devotion from library developers to make it work with a great set of compilers. Now I'm not saying that we should continue to support C++08 for every new library. Of course not. But we should make it a requirement if (1) abstractions are readily available without significant costs and (2) they don't offer significant advantage over older c++ versions. Both (1) and (2) are available on the abstraction layer offerred by ASIO. And since Boost.HTTP *is* a clear extension of ASIO, I expect it to use it. It's what the users should expect just by looking at it. And best of all? This is exactly Vinicius thoughts according to the Roadmap. So this should be done now. - 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? - Ignoring ASIO Abstraction Again, and already pointed out by Niall, Boost.HTTP should use ASIO's abstraction. A lot of work and thought has been put into this mechanism. Ignoring it in a library that extends it is not an option from my point of view. Boost.HTTP must support and use consistently all Boost.ASIO's mechanisms for abstraction. If I wish to use non-Boost ASIO, technically, Boost.HTTP should work. What could be a reason not to support this is ASIO has the abstraction ability? - 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. - 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. - Examples At the moment, there is only one example [3]. Examples are the very first thing I look at for Boost libraries. We need more. I talked to Vinicius and he pointed me to deleted examples that might work as a base [4]. Examples for handler based communications, coroutines, continuation, chunked, file server (included in the library) should be available again. Boost.ASIO's documentation is also great, and could be an inspiration. Same goes for Tutorial. - HTTP 2.0 Will it be added in Boost.HTTP? Will it be a separate library (Boost.HTTP2)? - 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. Best regards, Rodrigo Madera [1] http://boostgsoc14.github.io/boost.http/design_choices.html [2] http://boostgsoc14.github.io/boost.http/design_choices.html [3] https://github.com/BoostGSoC14/boost.http/tree/master/example [4] https://github .com/BoostGSoC14/boost.http/commit/21745f8dc81206f22445e43f9ab71a632c5a767f#diff- e3f28b5e7e2044a2e6332a5e997eabbaL86