What is the current status of Darren Garvey CGI library? 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? Darren, are you still working on this? I noticed the site says you had some study to get out of the way, we've all been there ;-) Cheers, Brad
Hi Brad,
2008/4/28 Brad
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.
Hello Darren, I have recently proposed (and sent a first version of) a CGI parameters parser for Boost.Program_Options. It obviously does not cover all what a complete CGI library can handle (it's not the goal) but permits to retrieve parameters just the same way as you would do with command line or config file parameters using Program_Options. And it takes advantage of the fact that this library already has some useful features like conversion into different data types. http://lists.boost.org/Archives/boost/2008/04/135607.php If you decide to release your CGI library into Boost, this CGI parser for Program_Options could become a simple binding to your code, providing a different way to easily access CGI parameters for people who don't need more advanced features. Regards Bruno
Hi Bruno,
2008/4/29 Bruno Lalande
Hello Darren,
I have recently proposed (and sent a first version of) a CGI parameters parser for Boost.Program_Options.
I saw this but have been too busy to comment unfortunately.
It obviously does not cover all what a complete CGI library can handle (it's not the goal) but permits to retrieve parameters just the same way as you would do with command line or config file parameters using Program_Options.
There's actually a bit in the CGI 'spec' about command-line parsing, here: http://rfc.net/rfc3875.html#s4.4. I was going to address that _eventually_ - it should literally take only a few extra lines of code - but if your patches were accepted I wouldn't have to, or want to since I prefer your solution. A Program_options patch should work fine in the minority cases mentioned in the link above, plus, the ability to use config files as well is very appealing (easy troubleshooting; automated testing; accurate benchmarking, anyone?). Nice idea.
And it takes advantage of the fact that this library already has some useful features like conversion into different data types.
FWIW, I plan to provide this kind of thing in the CGI library too.
http://lists.boost.org/Archives/boost/2008/04/135607.php
If you decide to release your CGI library into Boost, this CGI parser for Program_Options could become a simple binding to your code, providing a different way to easily access CGI parameters for people who don't need more advanced features.
Sure, go for it! Besides, who knows if the CGI library will ever get up to Boost's standards?! :) Cheers, Darren P.S. If there's still interest, I'll hopefully be able to request a formal review in the next few months.
participants (3)
-
Brad -
Bruno Lalande -
Darren Garvey