All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

I've got to agree with you, at least in terms of people using mod_perl for super-CGI rather than using mod_perl's strengths.

At Red Hat, we did a little of both. CGI-type scripts for short-term or one-off projects, and sometimes for prototypes. But most of redhat.com was running under Apache::ASP (that might have changed by now, though). The guys who cooked up the rhn.redhat.com site used their own ASP-like system, but it too was done as a location-handler, not a souped-up CGI library.

Unfortunately (and I willingly risk the wrath of any current co-worker who sees this), my every effort to develop applications using the full mod_perl platform at my current gig have met with resistance. They feel that the performance of Apache::Registry is comparable to a more integrated mod_perl location handler, and the latter requires server re-start when you update it, whereas Apache::Registry can better handle hot-swapping of code. After the first couple of times, I quit arguing.

There are real problems with Apache::Registry, principally with the magic required to turn your CGI into a module and what that does to your subroutines. Also, reloading things on the fly, while easy to add to handlers with Apache::Reload, will kill your shared memory, and should not be allowed on a production server.

If you must use Apache::Registry, use something like CGI::Application so that you can avoid all of the subroutine traps that Registry causes.