Re: [Pas-dev] Run Mulitple Apps in the same Apache instance...

[Mental P. <me...@ne...>]

On Thu, 2003-04-03 at 10:00, Kyle R . Burton wrote:
> - Org::Bgw::Config uses a singelton pattern.  The singelton is at the=20
>   package level.  This means that you can't have multiple configurations
>   loaded.  A requirement for multiple applicaitons.  An approach
>   for solving this (and not incuring the performance hit of loading
>   the configuration on every request) is not clear to me at this time.
> - Org::Bgw::Environment pulls the location of the configuration from
>   an environment variable.  This was originally done because it was
>   portable beteween the mod_perl and standard CGI worlds.  If we gave
>   in and just decided to support mod_perl, we could use a PerlVar=20
>   directive instead of SerEnv/PerlSetEnv.  PerlVar has the advantage
>   that it can be localized to either an Apache Location configuration
>   directive, or a Directory directive.  This would allow mutliple
>   configurations, localized to an alias (in the case of a Location=20
>   directive), to be supported.

I think we should stop trying to support CGI. Any sizable app that tries
to run in CGI mode is going to be very slow and non-scalable. This would
also open the door to us setting varabiles with perlsetvar as you
pointed out.

What if we subclassed the requesthandler on a per-application basis?
Register a uri /cust1 /cust2. Each one has a slightly different request
handler that is specific to their app. Can the request handler take a
parameter and deal with getting config pointed to the right place? Then
again, perlsetvar in a location block would do too.=20

=20
> - Any singelton pattern must be reworked to include a parameter to
>   identify the singelton to be retreived.  In the case of the configurait=
on
>   it might just be the full path and file name of the configuration file.
>   Or we could introduce a new PerlVar that acts as this kind of switch.
>   Perhaps we could just use the virtual-host's name?  That might be a goo=
d
>   approach for solving alot of these issues.

We could also look at using the uri. dev.domain.com/cookbook would be
different from dev.domain.com/icecastcontrol that way.=20

> - Developers would have to know the implications of using globals, static
>   variables - singeltons by any other name.
>=20

They sort of have to now, but yes. That would be an issue. Then again,
developers would be sharing pas/src, and still have their own pageobject
directory where singleton/static whatever wouldnt matter. This sort of
cames back to an idea I was kicking around about making the default page
psp's derive from easily configured/subclassed....=20



>=20
> Beyond that, can we solve the ISP's delima?  So that mod_perl/Pas could
> be used in a web-hosting type of environment where tens or hundreds of
> seperate web-sites all run in the same suped-up Apache process?  Is
> Apache2/mod_perl2 working on this problem?  To summarize, the problem
> here is that the mod_perl namespace is shared - so if I set a variable
> in my codebase $Foo::Bar, anyone else running in the same Apache instance
> can access it (and worse, change it).

Cant really speak to this. The solution is of course... colocation.
Beyond that, I cant think of a serious answer to this. I havent read
much on modperl for apache2 yet.=20


--=20
Mental (Me...@Ne...)

"Shouting at people who, for one reason or another, cannot hear you=20
is mentally-ill behavior -- or evidence of idiots in command."

--George Smith, a virus researcher and columnist for SecurityFocus.=20

CARPE NOCTEM, QUAM MINIMUM CREDULA POSTERO.

GPG public key: http://www.neverlight.com/pas/Mental.asc