I have always hated how difficult debugging CGI is, so I decided to do something about it. I grabbed a copy of Perl Web Server form Source Forge and went to work.
After a coupla days a hack'n I had a web server that would eval my CGI scripts and CGI::Applications. I could now set a break point in my CGI script and start the web server in the debugger. Then open a browser to port the web server is listening. This allowed me to interact with my CGI script through the browser. I find this easier than setting every thing up on the command line, especially for queries with 20 or more name value pairs.
After getting the debugging down I saw that was just the tip of the ice burg for making CGI development and debugging easier.
I modified CGI and CGI::Carp to provide the option to save all state and request information from a fatal error with Storable to a file. I added a new page to my CGI script so I could view the detailed information in the error files. As well as the ability to execute the offending request. You say why would I want to execute the falling request again? You would want to do that from the debugging web site, in the Perl Web Server debugger. Then you can quickly track down where the error is and fix it.
No more sifting through logs, or having to guess what the user did to get the error they are reporting. Get right to it, and fix it.
I have plans to add a test harness to it so in development you can create the same files the CGI::Carp creates for fatal errors and use them as the test case input. Then save and associate the output from those successful for future tests. When an error occurs on your production system you can grab the error file that CGI::Carp generated and fix the problem. After fixing the problem you make a new output file and associate it with the error file generated by CGI::Carp and run the test harness with the old and new test case to see if you broke anything while fixing the bug.
So I have some questions for anyone that is reading this. Is this so specialized a solution to my needs that others would not find much use in it? If not how do I give this to the Perl community, is it a tool, a set of libs, a hack or some combination of those choices? Do I need to contact the authors of the modules I needed to modify before I submit it to the Perl community? I just don't know what etiquette is in this situation.
So I have some questions for anyone that is reading this. Is this so specialized a solution to my needs that others would not find much use in it?
It sounds pretty useful to me. I spend 50% of my time writing CGI::Application modules and I'd love an easier way to debug them. Also, I know other people are working on the same problem. Someone emailed me with information about how to setup Apache to debug CGI::App modules from Komodo. I haven't had a chance to try it yet but it sounds similar to what you've done.
If not how do I give this to the Perl community, is it a tool, a set of libs, a hack or some combination of those choices?
The most successful Perl projects are modules on CPAN. If you can figure out a way to make it a module then you should. Keep in mind that modules are allowed to distribute scripts too (ex. Mail::SpamAssassin includes spamd and spamc).
Do I need to contact the authors of the modules I needed to modify before I submit it to the Perl community? I just don't know what etiquette is in this situation.
It's not a bad idea, but hardly required. I think you should at least post about it to the CGI::App mailing-list since I bet you'll find most of your users there.
Still have more questions about open-sourcing Perl code? Why not buy my book?
-sam
Re:How to give it back
jflowers on 2003-04-26T18:56:40
That other person is me, I emailed you.:)
Thanks for your help.
