Perl in shared hosting environments
bobtfish at bobtfish.net
Wed Sep 21 21:53:22 BST 2011
On 21 Sep 2011, at 16:49, Randal L. Schwartz wrote:
> You forgot:
> * My application only requires content generation, and I can
> ignore the other 14 phases of serving, because I don't want custom
> redirects, authentication, authorization, mime interpretation, and/or
> logging and other things written in the language of my choice: Perl.
> Seriously... *nothing* can compete with mod_perl as far as its reach
> into Apache. *Nothing*. With mod_perl, you can inject new behavior
> every level of decision making that Apache does. FastCGI is replacing
> just *one* of those 14 stages.
This is spot on. There are no magic bullets. :)
The main advantage of mod_perl is that you can completely mess with
apache, at every level (including turning it into an SMTP server, if
you so desire). This _is_ useful.
The main disadvantage of mod_perl is that people have (ab)used/do
(ab)use this a lot for _simple cases_ where you really only want to
generate web pages. A pile of <Location> blocks dispatching into
discrete mod_perl handlers works - but not adding the appropriate
abstraction here leads to code that is non-modular, hard to test &
debug and generally crappy (everyone has a crawing-horror mod_perl app
story or two!)
Having the level of separation implied by using fcgi (or proxying, or
whatever - generally making your app a .psgi (these days) no matter
how you deploy it) is generally massively superior to test and develop
on, and very few cases actually want or need the power of mod_perl..
More information about the london.pm