On Oct 26, 2005, at 11:15 AM, Tom Metro wrote: > I've often wondered if this greater power in mod_perl has been a > hindrance rather than a help to the Perl web development community. > Would we have been better off if, in addition to mod_perl (for the > rare > cases when you do need low-level access), there was a > mod_perl_embed, or > something like that, that was restricted in ability and focused on the > needs of the typical site developer?
An admin doesn't have to allow the developer full access to everything mod_perl can do. A common configuration used with mod_perl is to service only static HTML requests on the "main" server, and proxy requests to mod_perl serviced URLs to a separate server instance that's listening on a "high" port. This proxy set-up can be set up on a virtual server basis, with each virtual server having its own mod_perl instance. That does require a separate Apache instance, but not a dedicated server. The mod_perl Apache, being a separate instance, would not need to run as "nobody" or "www" - it could run with the user's permissions. Or, in a more secure setup, an admin could create two users, "joe" and "joe_perl", and add them both to "joe_group". Joe would use "joe" to log in, and the mod_perl server would run as "joe_perl". Joe could then allow the server access to specific files through the use of group permissions. Further, Joe wouldn't need to be given full access to the mod_perl server's configuration. The admin could configure it to service a particular URL/directory using Apache::Registry, with no overrides allowed. That would provide what many (if not most) people are really looking for when they mention mod_perl - a persistent environment in which to run CGI-like scripts. 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
