perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <>
Subject Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
Date Tue, 11 Jan 2005 00:12:48 GMT
Pratik wrote:
>>I would like to support Randal's contention (if not his tone) that
>>indeed, in real-world mod_perl commercial situations that I'm familiar
>>with (say about 8), 80% of those real-world users will want to have both
>>mod_perl 1 and mod_perl 2 installed concurrently due to the
>>generally-accepted production practice of "if it ain't broke, don't fix
>>it".  By virtue of being actual mod_perl, they already have production
>>mp1 installations.  They will also want to be moving forward with
>>leading, new releases for development of new systems, that is, mp2.
> How difficult is it really to have two different perl installation
> !!?? It's a one time cost you have to pay for the principle - "if it
> ain't broke, don't fix it". In fact - doing it actually applies that
> principle in practice.

Indeed, this is one of the non-Apache2 solutions I was thinking of.

Call it the "separate perl" solution if you wish.

You keep multi-API Apache::, get rid of the API overloading "use 
Apache2" workarounds, and replace them with a (I suspect... let me think 
on it more) a relatively simple MakeMaker or Module::Build extension 
that detects and FORCES a complete parallel perl install.

Much of the workaround hackery is due to trying to have the two 
mod_perls live inside the same perl. If you keep the same namespace, but 
abandon the option of living inside the same perl, a lot of the 
complexity of the workarounds go away.

We still have issues with multi-API, but it does solve what I would 
consider to be the nastier one of the two, and doesn't require changes 
to either legacy OR newer mod_perl2 code.

Or so it would appear from here. Comments?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message