Boost logo

Boost :

Subject: Re: [boost] [GSoC 2014] Http Server Proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-03-07 12:46:49

On 7 Mar 2014 at 4:25, Vinícius dos Santos Oliveira wrote:

> I'm sorry for taking so long to present my proposal, but some
> unpredictable events delayed the available time I had to work on the
> proposal and the large number of mentions you guys made turned my work
> into a task more difficult.

Firstly, this is a not bad initial design given your unfamiliarity
with Boost. Its biggest problem is vagueness in some key areas, but
as a review of the existing approaches it's not bad.

I'll just make some observations:

* ASIO can use futures or callbacks. It can use threads or
coroutines. Error handling can be an error code or exceptions. In
short: ASIO is very flexible. The N3964 paper simply seeks to
standardise ASIO's already existing design, so all those facilities
are already there and available.

* AFIO is probably not hugely useful except for doing async file i/o
which ASIO can't do, despite what ASIO claims in its docs. In other
words you'd bring in AFIO for the static content backend where for
example you can enumerate directories asynchronously, otherwise AFIO
is overkill.

* I would very seriously reduce the scope of your present proposal.
Just to write a semi-decent fully asynchronous static content HTTP
1.1 server is more than enough to consider right now. I'd forget
about any CGI or anything else like that for now. I'd *even* suggest
restricting scope to HTTP 1.0 support as your first milestone, and
then slowly extend out into HTTP 1.1.

* You mentioned "The implementation of a HTTP server isn't very
challenging". Algorithmically you're right, but the fact people keep
reinventing HTTP servers shows how hard implementing a *good* HTTP
server is. HTTP servers are a good example of why a compsci whiz or
an algorithms whiz can make lousy "real world" programmers. The hard
part of a decent HTTP server is getting to a 100% asynchronous
internal engine which is exception safe and linear scalable to load.
I would *not* underestimate how hard one of these is: I would
personally estimate about 1000 hours for me to implement just a fully
async HTTP 1.0 static content server with validation and test suite
and Boost quality documentation. If you think that proposed
Boost.AFIO - which is just 1000 active LOC by the way - has consumed
about 600 hours, and it's a fraction of the complexity of a HTTP 1.0
server, you'll see what I mean.

Good luck!


Currently unemployed and looking for work in Ireland.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at