Hi Brad,<br><br><div class="gmail_quote">2008/4/28 Brad &lt;<a href="mailto:boost@brand-hubs.com">boost@brand-hubs.com</a>&gt;:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What is the current status of Darren Garvey CGI library?<br>
</blockquote><div><br>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.<br>
<br>I also hope to find some common ground with the people working on a networking library for boost (cppnetlib @ <a href="http://sf.net">sf.net</a>). I&#39;m not yet sure where that common ground could/should be.<br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I am starting a CGI project and am wondering whether this is mature<br>
enough for the job? At the moment I am only looking at CGI but I may<br>
need FastCGI, etc. at a later date. My current opinion from looking at<br>
the source downloaded from <a href="http://cgi.sourceforge.net" target="_blank">http://cgi.sourceforge.net</a> is that it will be<br>
suitable. Anyone know of any alternatives?<br>
</blockquote><div><br>I&#39;m very glad you think so. There is always cgicc (<a href="http://gnu.org/software/cgicc/">http://gnu.org/software/cgicc/</a>) as an alternative - it&#39;s very mature, compact and fast, but perhaps pays a price for having so many legacy users... [1]<br>
<br>To be perfectly honest, while I&#39;d like to think the F/S/CGI library is definitely &quot;on it&#39;s way&quot;, the code (and my untrained eyes) could always do with more input from the experts. If you&#39;re just planning to use CGI for now, I&#39;d humbly encourage you to try it and would offer what support I could for your needs. I&#39;m very interested in knowing what people expect from such a library.<br>
<br>FWIW (dealing with the major issues):<br><br>* Top of my TODO list is getting the testsuite up to scratch.<br>* Second is getting FastCGI working on Windows.<br>* Third is having a decent implementation of the form_parser class - for efficiently and flexibly dealing with POST data in a generic way.<br>
* Fourth is allowing different types of connections to work efficiently, at compile-time *or* runtime with FastCGI requests (ie. you can have either an &quot;implementation-defined local socket&quot; or a TCP connection between FastCGI daemon and server).<br>
...<br>* A bit further down is adding services for using debug output/error streams. (this might actually be easy to implement, once I&#39;m sure of the best way to do it).<br>...<br>* Adding a dynamic_request class that could handle both CGI and FastCGI transparently. This isn&#39;t particularly hard to do but would incur some runtime overhead. I&#39;m still not sure the overhead is worth it, but feel free to tell me otherwise - noone has so far!<br>
<br>Anyway, back to work for me. Feel free to email me privately if you prefer.<br><br>Regards,<br><br>Darren<br><br>[1] Actually, replicating the performance of cgicc is one of my goals here - it&#39;s the classic &quot;genericity isn&#39;t always slower&quot; 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&#39;t match the efficiency of cgicc, while being easier and safer to use, but we&#39;ll see.<br>
</div></div>