Re: [boost] [GSoC 2014] Http Server Proposal

Subject: Re: [boost] [GSoC 2014] Http Server Proposal
From: Bjorn Reese (breese_at_[hidden])
Date: 2014-03-09 10:52:23

On 03/08/2014 02:54 AM, Vinícius dos Santos Oliveira wrote:

>> https://github.com/vinipsmaker/gsoc2014-boost

This is a strong and well-researched proposal. I volunteer as a mentor
for this project.

I have some suggestions for improving your proposal. Do not let the
sheer volume discourage you; you are definitely on the right track.

List the overall goals more clearly at the start. For example:

   1. Targets embeddable HTTP servers (e.g. to implement ReST APIs).
      These servers should be able to co-exist with other embeddable
      communication facilities (e.g. Bonjour device discovery or
      BitTorrent.)
   2. Create a C++ toolbox for embeddable HTTP servers.
      This requires a modular design and a coherent thread model.
   3. Flexible design that can encompass HTTP chunking, HTTP pipelining,
      WebSockets, FastCGI, etc.
   4. Scalable performance.
      This requires an asynchronous design.
   5. Reuse existing std or Boost components, such as Boost.Asio.

You should introduce the overall design (messages, connections, and
backends) before discussing performance. Otherwise, your performance
discussion is going to be hard to follow. You should also describe
how the distinction between header and body, and especially how
streamable bodies (HTTP chunking and WebSockets), fit into the design.

Most of the performance discussion should be moved to a separate
section. For instance, I do not need to know about an extra level of
indirection this early in the proposal.

Good discussion about the other HTTP servers. I have the following
comments though: The discussion on Twisted is inappropriate for a
proposal. You should either investigate Twisted or remove the section.
Furthermore, you should look into Pion.

The proposal does not mention Request-URIs, and thus makes no reference
to the C++ standard proposal N3625.

Concerning your HTTP server design, you currently have a server
backend that the user must implement to obtain HTTP requests via
the async_handle() functions. This makes the user a passive party in
the design, who only has to react to incoming requests. I suggest that
you consider a design that is closer to the Boost.Asio design. Let
the user become the active party, who asks explicitly for the next
request. This can be done by adding async_send() and async_receive()
functions on the http::server::server class. These functions should
handle partial transmission under the hood, so their handlers are only
trigger when an entire HTTP request has been received (or a response
has been sent.) This will render the backend superfluous.