mod_perl allows for programmatic control of all phases of the request cycle for the popular Apache webserver...

Or put another way ... mod_perl exposes the the Apache Webserver API to Perl and thus exposing the API to the Perl Programmer.

This has always suggested to me a much more powerful flexible way of extending apache functionality than just a backend transaction handler (CGI). The trick has always been to step outside of the 'CGI BOX' by asking ourselves how can I extend the server to do what I want. This is in fact the approach with newer server technologies like 'Tomcat' take.

The problem with mod_perl in my view is that it has never been 'formally' exploited. It solved one big problem almost from its birth: run CGIs faster and then got pidgeoned holed. It is easier just to write mod_perl friendly CGI's then delve deeper into designing and implementing trans_handlers and such. The deeper more interesting ways of using mod_perl, after some initial interest, never got persued. PHP exploited this lack of interest and snuck right up the middle or should I say 'right up the apache request cycle'.

But I am still using mod_perl but not exclusivley, recently our projects have begged for other solutions as the need for more specialized servers continues to grow. As usual princepawn in his special way has got me headed towards another head space minefield. What we really need is a formal structure in which to create Perl extendible 'Application Servers'. There I said it the 'A' word. Are you happy now princepawn.

mitd-Made in the Dark
'My favourite colour appears to be grey.'