Re: [boost] [http] Formal review of Boost.Http

Subject: Re: [boost] [http] Formal review of Boost.Http
From: Rodrigo Madera (rodrigo.madera_at_[hidden])
Date: 2015-08-11 16:26:20

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