Boost logo

Boost :

From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-04-25 12:53:21

Hi Jose,

On 25/04/07, Jose <jmalv04_at_[hidden]> wrote:
> I forgot to ask, which cases below are you targeting ?
> (i thought 1, 2, 3)

If the 1,2,3 implies the three emails, I'll just clarify that _everything_
to do with 'output formatting' is excluded from the library. Provisionally,
the only output ability will be via operator<<, write(), write_file() - for
a response that is a file - and print_file() - for a response that
_contains_ a file as well as other data. (feel free to disagree)

On 4/23/07, Jose <jmalv04_at_[hidden]> wrote:
> >
> > Hi,
> >
> > The project should make it clear how it supports different needs and it
> > allows a basic to advanced path:
> >
> > CGI: support to allow any c++ program to output results to a browser
> > (typical cases are to output a html or an image via a web server)
> >
> > FCGI,SCGI: support to build a server deamon that interfaces to a web
> > server via tcp sockets (e.g. apache front-end via mod_fcgi to a custom
> c++
> > daemon)

This is the main focus of the SoC project.

> Web server: support to build a basic web server tied to a c++ application
> > but with the web server also supporting CGI/FCGI on the server-side (
> e.g.
> > improved asio http server)

This would, of course, be nice. However I'm not sure how much of a mammoth
task it'd be. Support for general HTTP would come first, that would be the
first step to a full-blown server. Obviously, I don't have any delusions
about this getting done any time soon (or even by me at all - someone might
beat me to it).

> Advanced - simulations, debugging: support to build a web server thread
> > that can be used to debug the application or to query the status of a
> long
> > running application via a web browser
> > <> (see
> >

Debugging would be very handy although, again, this isn't planned for this
summer. Being able to query the status of the program would be possible
using the planned structure: stuff like the number of requests handled,
request queue size, etc. would all be accessible via the 'service' class.
However, the ability to do it via a web browser wouldn't be part of the

One way to do this would be to use asio to have the main program (a FastCGI
responder, for instance) to set up a listening socket, which could take
queries and translate them into actions on the 'service' object, returning
the result. To make this info accessible via a browser, all you'd need to do
is set up a program that accepts cgi requests, connects to the listening
socket on the main program, and acts as a gateway for the



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