On Oct 27, 2005, at 7:26 AM, David Cantrell wrote: > On Wed, Oct 26, 2005 at 04:12:30PM -0400, Sherm Pendley wrote: > >> An admin doesn't have to allow the developer full access to >> everything mod_perl can do. > > Oh? I thought it was always possible to delve into Apache's guts.
Not at all. To add a new handler, you need to have access to the Apache configuration directives to do so. You can restrict the user's ability to use those directives in their .htaccess. No, it wouldn't be as flexible. But really, what are most people looking for when they say they want mod_perl? Do they want to use DBI in an authorization phase handler to look up user names in a PostgreSQL database? Some do, but not many. What most want is just a quick, persistent, CGI-like environment. >> A common configuration used with mod_perl is to service only static >> HTML requests on the "main" server, and proxy requests to mod_perl >> ... >> >> This proxy set-up can be set up on a virtual server basis, with each >> virtual server having its own mod_perl instance. > > Admins don't like this. It's more maintenance, and mod_perl is a big > fat memory-eating pig. It can be trimmed down a lot. If you're only providing your customers with access to Apache::Registry, there's no need to build in support for other request phases. You could set appropriate resource limits for the mod_perl user account(s). Or, you could set up a simple monitor script that periodically checks the memory usage of your mod_perl Apaches - and charge a "memory pig" fee to those users who consistently go over a specified amount. When I was working in hosting, we had a motto. Actually, we had several, but this one's relevant: "Never tell the customer 'no'. Tell them it will cost extra." sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
