On 10/26/05, Sherm Pendley <[EMAIL PROTECTED]> wrote: > 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. [...]
The memory requirements of Apache with mod_perl are such that you can serve far fewer users per machine this way than you can with PHP. Given how competitive the shared hosting business is, it would be hard to do this at a competitive price. Cheers, Ben _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
