From: Michael Dickey (mike_at_[hidden])
Date: 2007-12-10 18:58:23
On Dec 10, 2007, at 2:12 PM, Phil Endecott wrote:
> Michael Dickey wrote:
>> On Dec 10, 2007, at 6:39 AM, Phil Endecott wrote:
>>> Far from merging your library into something else, I encourage you
>>> see how much you can break it up into smaller chunks and to make it
>>> compatible with, yet not dependent on, other libraries.
>> It's definitely moving in that direction. For example, you can use
>> the client-side part of the library without touching any server-side
>> stuff, and you can even parse HTTP messages without any networking
>> code. I agree with the approach of breaking pieces out and pushing
>> them into a lower-level space like cpp-netlib over time.
>> I guess a big question is, does _server-side_ functionality belong in
>> Boost? I think for most cases, you're going to use an external
>> packaged server to solve a problem.
> I might have agreed with you a few years ago but recently I've come to
> the conclusion that it's better to just implement an HTTP server. In
> the past I have written CGI programs, which have the problem of
> starting one process per request, and Apache modules, where I have
> Boost.Interprocess to store inter-request data. Just writing an HTTP
> server is simpler and better, and you can get Apache features
> (compression, encryption, authentication, etc. etc.) by using its
> mod_proxy to forward requests to your separate server.
I agree; that's why I wrote the library: to make it really easy to
embed your own HTTP server =)
I think what I was trying to say is just that for most servers, taking
an embedded/roll-your-own path is hard to justify. But HTTP is
becoming somewhat of a special case, in that it's more often easier to
justify embedding a simple server in your application, versus
integration with an outside server using CGI or some other API.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk