On 12/31/04 4:40 PM, Stas Bekman wrote: > Finally you don't want to use it - don't use it. It's an open source > software, it will succeed or fail by *its own merits* and not because the > infrastructure has a long known problem but is not willing to evolve. > > And to repeat this again. If you install only mp2 under the given Perl, > all those hours spent in trying to stop the evolution are a total waste, > since mp2 has no problem what so ever. None of the problems discussed in > this and many other similar threads is relevant. They are relevant only to > a few people who for some reason want to have both modperl generations in > the same tree. And you will be able to count those with your fingers on > the left hand. So let's hurt 99.9% of users, because 0.1% will have it a > bit harder than the rest.
I think the infrastructure thing is a red herring. Unless the "native" mod_perl 2 API is 100% compatible with mod_perl 1 (it isn't), mod_perl 2 shouldn't be in the same CPAN namespace as mod_perl 1 if mod_perl 1 will continue to exist (it will). This is regardless of whether or not I or anyone else plans to have both mod_perl 1 and 2 installed at the same time. It's simply The Right Thing to Do, IMO. It's also one of the easiest solutions for the mod_perl 2 core team. If third party Apache:: CPAN module authors have objections, let them speak up (although they probably won't change my opinion--see previous email). But so far, I mostly see mod_perl 2 core people making the third-party module argument by proxy (okay, granted, many of them are also third party Apache:: module authors...too many hats! :) Anyway, I don't think the mod_perl 2 core team has anything to fear from massive third-party Apache:: module abandonment. They'll be ported if there's a need, and more likely than if a port didn't have the opportunity to change the API as well as the implementation. -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html