Re: [Boost-users] Boost CGI

From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2008-04-28 17:58:28

Hi Brad,

2008/4/28 Brad <boost_at_[hidden]>:

> What is the current status of Darren Garvey CGI library?
>

I have some study left to do, but the library is still coming on - albeit
painfully slowly... As soon as I get some time I hope to be able to use the
brand-spanking-new Asio features to make FastCGI work like it should, on all
platforms.

I also hope to find some common ground with the people working on a
networking library for boost (cppnetlib @ sf.net). I'm not yet sure where
that common ground could/should be.

I am starting a CGI project and am wondering whether this is mature
> enough for the job? At the moment I am only looking at CGI but I may
> need FastCGI, etc. at a later date. My current opinion from looking at
> the source downloaded from http://cgi.sourceforge.net is that it will be
> suitable. Anyone know of any alternatives?
>

I'm very glad you think so. There is always cgicc (
http://gnu.org/software/cgicc/) as an alternative - it's very mature,
compact and fast, but perhaps pays a price for having so many legacy
users... [1]

To be perfectly honest, while I'd like to think the F/S/CGI library is
definitely "on it's way", the code (and my untrained eyes) could always do
with more input from the experts. If you're just planning to use CGI for
now, I'd humbly encourage you to try it and would offer what support I could
for your needs. I'm very interested in knowing what people expect from such
a library.

FWIW (dealing with the major issues):

* Top of my TODO list is getting the testsuite up to scratch.
* Second is getting FastCGI working on Windows.
* Third is having a decent implementation of the form_parser class - for
efficiently and flexibly dealing with POST data in a generic way.
* Fourth is allowing different types of connections to work efficiently, at
compile-time *or* runtime with FastCGI requests (ie. you can have either an
"implementation-defined local socket" or a TCP connection between FastCGI
daemon and server).
...
* A bit further down is adding services for using debug output/error
streams. (this might actually be easy to implement, once I'm sure of the
best way to do it).
...
* Adding a dynamic_request class that could handle both CGI and FastCGI
transparently. This isn't particularly hard to do but would incur some
runtime overhead. I'm still not sure the overhead is worth it, but feel free
to tell me otherwise - noone has so far!

Anyway, back to work for me. Feel free to email me privately if you prefer.

Regards,

Darren

[1] Actually, replicating the performance of cgicc is one of my goals here -
it's the classic "genericity isn't always slower" argument. My tests have
been limited but show that I still have work to do with CGI. FastCGI
performance in this library seems to beat cgicc, but I doubt the results. I
see no reason why this library can't match the efficiency of cgicc, while
being easier and safer to use, but we'll see.