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

Subject: Re: [boost] [GSoC 2014] Http Server Proposal
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2014-03-09 23:18:30

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