Em Dom, 2014-03-09 às 15:52 +0100, Bjorn Reese escreveu:
This is a strong and well-researched proposal. I volunteer as a mentor for this project.
Great. And thanks for the detailed feedback.
List the overall goals more clearly at the start.
Good idea. Now the proposal has some points before the design consideration at the very beginning of the text. Maybe I can add a small paragraph detailing why this proposal is important to boost too.
For example: [...]
I added this list to my proposal at https://github.com/vinipsmaker/gsoc2014-boost#some-target-scenarios . I hope you don't mind (text is quoted anyway). It seems you understood my proposal very well.
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.
I'm working on that.
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.
Done.
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.
Done
Furthermore, you should look into Pion.
I'm working on that.
The proposal does not mention Request-URIs, and thus makes no reference to the C++ standard proposal N3625.
I'll fix it soon.
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.
Actually, the documented design is pretty vague yet. It doesn't make much sense to double document here on the list and there on the MarkDown file, then I'll be brief now and work there. I can warn about the update later. So... briefly, the backend is not meant to register user callbacks. It's meant to abstract different communication mechanisms (builtin HTTP server, FastCGI, CoAP, ...) to the request and response objects. It could be used to obtain new HTTP requests too, but I'll have to think more about this when it's time to detail http+https+threaded design (the user might be interested in use the same handlers for all backends).
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.
Looks like you're worried about an active design that is closer to ASIO. I'll keep that in mind.
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.
My idea was to separate users handlers from the associated connections. Handlers would only interact with request and response object, which, in turn, would interact (by dispatching) with the abstract backend class. About the active or passive party style, it'll lie on the "gluing" mechanism, which is still undecided. Think about sockets configured through an acceptor, for instance. You don't want to go through the acceptor to send a message with/to the socket. About the same happens within a HTTP session. You don't want to go through the backend to respond to a new message. Your callback will be called with the request and response objects and you only want to use the response object to respond to the request. I'll ask for a re-review of this part once the design is more clear and documented. And again, thanks for the detailed feedback. I'll go back to work on the document proposal. And maybe of your interest, I've spent some time playing (and testing) with some ASIO examples to better understand its behaviour under some conditions (eg. send message with an unconnected socket, lifetime management with slightly complex scenarios, simple ordering, ...). This effort will help me to document a design closer to ASIO proposal. In fact, the will verb in the previous sentence is wrong, because the invested effort already **is** helping me with the proposal. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker