On 03/08/2014 02:54 AM, VinÃcius dos Santos Oliveira wrote:
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.