Bjorn Reese
2015-08-27 16:21:56 UTC
The outcome of the formal review of Boost.Http is that the library is
NOT accepted for inclusion into Boost this time.
Below I will first summarize the main themes running through the
review, and afterwards I will make some recommendations about how to
proceed from here.
The following reviews were posted:
- Antony Polukhin: No
- Darren Cook: No
- David Sankel: No
- Lee Clagett: No
- Niall Douglas: Yes, conditionally
- Roland Bock: No
- Tom Kent: No
The discussions were constructive and offered much valuable feedback.
There was a general consensus that Boost ought have a HTTP library,
but that Boost.Http was too incomplete in its present state.
Many reviewers mentioned the disconnect between their expectations and
what the library offered. There were several suggestions for alternative
names for the library to better reflect the feature-set it offers.
Boost.Http currently only provides a server-side API, but the reviewers
felt that a client-side API would be usable to more users.
There was also a recurring request for Boost.Http to be a header-only
library. The HTTP parser currently used is not header-only and that is
the main obstacle towards a header-only Boost.Http library.
Some of the discussion revolved around what level of abstraction would
be appropriate for Boost.Http. The views ranged from wanting higher-
level APIs all the way down to simply wanting a HTTP parser/generator
and then leave all the socket and buffer management up to the user.
Regarding the HTTP parser/generator, there is no reason why it cannot
be a separate Boost library. However, Vinicius correctly pointed out
that this is insufficient for a HTTP server framework that handles
multipleback-ends (e.g. HTTP/2, FastCGI, or WebSocket). By implication
it cannot handle HTTP upgrade requests either.
Some reviewers also felt that HTTP/2 should be part of Boost.Http,
partly because that would demonstrate the extensibility of the current
design, and partly because the library would be in a stronger position
to attract users if it offers more than its competitors.
There was concern about whether or not the Boost.Http API can be
extended to HTTP/2. The main challenge with HTTP/2 is fitting
multiplexing into the API. Vinicius suggested that there should be a
http::socket per multiplexed channel, so it will be transparent to
the user if several of his http::sockets to the same remote endpoint
are transported via the same TCP socket. This will keep the API clean
when extended to HTTP/2.
Boost.Http currently creates an associative array for all header fields.
One reviewer explored the idea of using an incremental (push or pull)
HTTP parser as part of the API to let users decide which header fields
to copy and which to discard.
There was a general consensus that more examples are needed, and that
the tutorial should have smaller examples.
The Boost.Http code base currently builds with CMake. This must be
converted into Boost.Build before being integrated into the Boost
code base.
Several other third-party tools were suggested, but as these are not
requirements for inclusion into Boost I will leave the decision to the
author.
As for the future, I hope that Vinicius is not too discourage by the
current rejection, and that he will consider re-submitting the library
at a later stage. Judging from the reviews, the following additions will
make a future submission more likely to succeed:
1. Involve the community more during the development. This will
both solicit earlier feedback on the design, and help to align
community expectation.
2. Provide a client-side API.
3. Design higher-level APIs on top of the low-level APIs.
4. Better documentation and more examples.
I also hope that people in the community will consider contributing to
the library. For example, a good opportunity is to help creating the
higher-level APIs. Another opportunity is to help with the (header-
only, possibly incremental) HTTP parser/generator, which could be a
separate library.
NOT accepted for inclusion into Boost this time.
Below I will first summarize the main themes running through the
review, and afterwards I will make some recommendations about how to
proceed from here.
The following reviews were posted:
- Antony Polukhin: No
- Darren Cook: No
- David Sankel: No
- Lee Clagett: No
- Niall Douglas: Yes, conditionally
- Roland Bock: No
- Tom Kent: No
The discussions were constructive and offered much valuable feedback.
There was a general consensus that Boost ought have a HTTP library,
but that Boost.Http was too incomplete in its present state.
Many reviewers mentioned the disconnect between their expectations and
what the library offered. There were several suggestions for alternative
names for the library to better reflect the feature-set it offers.
Boost.Http currently only provides a server-side API, but the reviewers
felt that a client-side API would be usable to more users.
There was also a recurring request for Boost.Http to be a header-only
library. The HTTP parser currently used is not header-only and that is
the main obstacle towards a header-only Boost.Http library.
Some of the discussion revolved around what level of abstraction would
be appropriate for Boost.Http. The views ranged from wanting higher-
level APIs all the way down to simply wanting a HTTP parser/generator
and then leave all the socket and buffer management up to the user.
Regarding the HTTP parser/generator, there is no reason why it cannot
be a separate Boost library. However, Vinicius correctly pointed out
that this is insufficient for a HTTP server framework that handles
multipleback-ends (e.g. HTTP/2, FastCGI, or WebSocket). By implication
it cannot handle HTTP upgrade requests either.
Some reviewers also felt that HTTP/2 should be part of Boost.Http,
partly because that would demonstrate the extensibility of the current
design, and partly because the library would be in a stronger position
to attract users if it offers more than its competitors.
There was concern about whether or not the Boost.Http API can be
extended to HTTP/2. The main challenge with HTTP/2 is fitting
multiplexing into the API. Vinicius suggested that there should be a
http::socket per multiplexed channel, so it will be transparent to
the user if several of his http::sockets to the same remote endpoint
are transported via the same TCP socket. This will keep the API clean
when extended to HTTP/2.
Boost.Http currently creates an associative array for all header fields.
One reviewer explored the idea of using an incremental (push or pull)
HTTP parser as part of the API to let users decide which header fields
to copy and which to discard.
There was a general consensus that more examples are needed, and that
the tutorial should have smaller examples.
The Boost.Http code base currently builds with CMake. This must be
converted into Boost.Build before being integrated into the Boost
code base.
Several other third-party tools were suggested, but as these are not
requirements for inclusion into Boost I will leave the decision to the
author.
As for the future, I hope that Vinicius is not too discourage by the
current rejection, and that he will consider re-submitting the library
at a later stage. Judging from the reviews, the following additions will
make a future submission more likely to succeed:
1. Involve the community more during the development. This will
both solicit earlier feedback on the design, and help to align
community expectation.
2. Provide a client-side API.
3. Design higher-level APIs on top of the low-level APIs.
4. Better documentation and more examples.
I also hope that people in the community will consider contributing to
the library. For example, a good opportunity is to help creating the
higher-level APIs. Another opportunity is to help with the (header-
only, possibly incremental) HTTP parser/generator, which could be a
separate library.