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

Subject: Re: [boost] [http] Formal review of Boost.Http
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2015-08-13 08:53:10

2015-08-11 17:26 GMT-03:00 Rodrigo Madera <rodrigo.madera_at_[hidden]>:

> [...]
>

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