Another point that was mentioned by someone in my local Mongers group was that of different INC paths for different sets of users. I confess not to have given this much thought but upon initial thinking it seems that if different users want to have isolated local modules (differing versions of the same module comes to mind...or just general privacy).
I am not sure if it is easy to achieve this level of compartementalization or not...but I guess an ISP would insist on that sort of thing. Fundamentally a separate memory space for each virtual server. Ugh, I don't like the sound of that. J > agreed that there is a *big* demand for this. No need to have an > advocacy thread on that :) Let's move onto the deep water. > > > > there are lots of problems with allowing users to have access to > > mod_perl in a multiple-client or mass web hosting situation. of > > course, the advocacy bent is that without this type of access, > > mod_perl will never reach the level of PHP (if we want it to, that is > > :) > > We need to adopt concepts of chroot jail. Have you looked at Opcode > module? If I remember correctly that's the module/functionality that we > need to integrate, so certain opcodes won't be available for the end > users. That's what we need, right? > > I think the first thing to lookat is how PHP builds the jail. > > _____________________________________________________________________ > Stas Bekman JAm_pH -- Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide http://perl.apache.org/guide > mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com > http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
