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-07 13:47:31

Em Sex, 2014-03-07 Ã s 17:46 +0000, Niall Douglas escreveu:

> * 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.

The main reason for my attention for CGI, multithread and so many other
features is to get a core design that works. I'm not planning to deliver
all features (I didn't write the timeline yet). Another reason to cite
so many features is to raise discussions (like this) and to help with
the arguments.

And my plan to get a "good" HTTP server is very simple: (1) expose the
HTTP power and (2) allow different backends (3) under a performant and
flexible API.

But you're right about a small set of core features that is (1) 100%
asynchronous, (2) exception safe, (3) linear scalable with (4)
validation, (5) test suite and (6) Boost quality documentation. My plan
to accelerate the development, like stated in the current version of the
proposal, is to reuse a HTTP parser being used heavily under production
around the world. And I wouldn't be interested in Boost if I was
expecting an easy task.

I'll spend the rest of the day finishing the "vagueness in some key
areas" that you mentioned. Thanks for the detailed feedback.

-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker