Re: mod_perl and shared environments don't mix

For programs that only run in Apache::Registry, that just might work. For programs that extend Apache itself, it probably won't work. To my knowledge, PHP doesn't give access to the full Apache API, so it does a whole lot less than mod_perl and is much easier to sandbox.

Comment on Re: mod_perl and shared environments don't mix - do they?

Replies are listed 'Best First'.
Re^2: mod_perl and shared environments don't mix - do they? by Aristotle (Chancellor) on Nov 10, 2002 at 13:57 UTC
Then I find that alone makes it worth investigating. (Make that one more item on my long list of ideas..) Most ready-to-install scripts come as mod_perl-friendly CGIs, with the main appeal of mod_perl besides the acceleration of the scripts themselves being persistent database connections. Just being able to run those in a shared environment would be a big boost. On the other hand, how much work would it be to offer a stripped down mod_perl that only offers enough of the API as to be sandboxable like PHP? Idly mulling, it seems it might even work to strip down mod_perl via httpd.conf rather than at compile time. Makeshifts last the longest.	[reply]

Replies are listed 'Best First'.

Re^2: mod_perl and shared environments don't mix - do they?
by Aristotle (Chancellor) on Nov 10, 2002 at 13:57 UTC

Then I find that alone makes it worth investigating. (Make that one more item on my long list of ideas..) Most ready-to-install scripts come as mod_perl-friendly CGIs, with the main appeal of mod_perl besides the acceleration of the scripts themselves being persistent database connections. Just being able to run those in a shared environment would be a big boost.

On the other hand, how much work would it be to offer a stripped down mod_perl that only offers enough of the API as to be sandboxable like PHP? Idly mulling, it seems it might even work to strip down mod_perl via httpd.conf rather than at compile time.

Makeshifts last the longest.

[reply]