Re: [boost] [soc07][cgi] RFC: use-cases/scope

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
> > <http://code.google.com/p/gperftools-httpd/> (see
> > http://code.google.com/p/gperftools-httpd/)

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

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
requests/responses.

[snip]

Cheers,
Darren