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?
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
