Perl in shared hosting environments

[Tomas Doran]

On 21 Sep 2011, at 16:49, Randal L. Schwartz wrote:

> You forgot:
>
> * My application only requires content generation, and I can  
> completely
>  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  
> at
> 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..

Cheers
t0m