In a way, mod_perl and mod_cgi are really solving two different problems. mod_cgi takes one file, and maps it to a url, thus doing some crunching then the url gets hit. mod_perl, on the other hand, is a much bigger hammer, and much more closely tied to Apache. People who glance at mod_perl often only see Apache::Registry -- but it's an important point to note that Apache::Registry, while an interesting hack that certainly does allow for CGI-like programs, is really only the tip of the iceberg of what mod_perl can do.

On the gripping hand, the tightness with which mod_perl is bound to Apache can cause no end of troubles -- from bloated httpd processes which slow down serving of static pages, to requiring copious restarts at every niggling change, to segfaults that are nigh-impossible to track down, causing one to spend eons of time, staggering amounts of frustration, and a small amount of hair.

Who me, bitter? ;>

I think mod_cgi will live on for a long time in the realm of short hacks that do only a short list of things, then are done with it. Anything more complicated, like the Everything system that Perlmonks uses, is probably better off with the tight httpd integration of mod_perl.

perl -pe '"I lo*`+$^X$\"$]!$/"=~m%(.*)%s;$_=$1;y^`+*^e v^#$&V"+@( NO CARRIER'