Perl in shared hosting environments

[Tatsuhiko Miyagawa]

On Wed, Sep 21, 2011 at 8:49 AM, Randal L. Schwartz
<merlyn at stonehenge.com> wrote:
>>>>>> "Dirk" == Dirk Koopman <djk at tobit.co.uk> writes:
>
>
> Dirk> Reason include:
>
> 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.

This is where PSGI stands out. If you write a couple of mod_perl
handlers that work on these 14 phases of serving, then it will *only*
work with mod_perl, putting aside the fact that mod_perl1 handlers
won't work with mod_perl 2.

If you write PSGI middleware that does URL rewrites, authentication,
authorization, custom redirects, logging etc. as PSGI middleware, then
you can use that with ANY of PSGI supported web servers (Starman,
mod_perl, FastCGI etc.) and ANY of PSGI supported frameworks
(Catalyst, Dancer, Mojolicious etc.)

You can see the examples of middleware by searching on CPAN:
https://metacpan.org/search?q=plack%3A%3Amiddleware

> 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.

True: you can further its reach into *Apache* and nothing else.

-- 
Tatsuhiko Miyagawa