perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Lawrence" <...@Lawrence.Net>
Subject Re: mod_perl 2.0 for ISPs - design docs
Date Sat, 05 Jan 2002 14:37:02 GMT
Stas,

Thank you for the link. I was not aware of this document. The PerlOptions
directive looks like an excellent design decision!

J
----- Original Message -----
From: "Stas Bekman" <stas@stason.org>
To: "Jay Lawrence" <Jay@Lawrence.Net>
Cc: "Geoffrey Young" <geoff@modperlcookbook.org>; <dev@perl.apache.org>
Sent: Friday, January 04, 2002 9:25 PM
Subject: Re: mod_perl 2.0 for ISPs


> Jay Lawrence wrote:
>
> > 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.
>
>
> Guys, I suggest that you read the design docs before you continue. The
> INC issue has been addressed already. Please read:
> http://apache.org/~dougm/modperl_2.0.html
> http://apache.org/~dougm/modperl_design.html
>
> The tests suite has a few tests already that test this issue. It works.
>
>
> >>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:stas@stason.org  http://ticketmaster.com http://apacheweek.com
> >>http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> >>For additional commands, e-mail: dev-help@perl.apache.org
> >>
> >>
> >>
>
>
>
> --
>
>
> _____________________________________________________________________
> Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
> http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
> mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message