As probably with most of you, I'm getting worried with the tone of the discussion on the mp2 namespace problem, and the directions it's heading - getting locked out of CPAN, etc. And, rightly or wrongly, getting a a sizeable fraction of the Perl community upset on the eve of the official mp2 release can't be a good thing ... Also, though, like Joe raised, it's upsetting that a good portion of the flames are directed at Stas, who has put so much into mp2, both inside and outside of the actual code.
The fundamental issue of using the Apache::* namespace for modules both in mp1 and mp2 sounds like an unresolvable one. On the one hand, at the level of a script or handler, Apache::Request (for example) in mp1 has a lot of the same interface as Apache::Request of mp2. However, Apache::Request itself built under mp1 can't be used under mp2, and vice-versa. A lot of this worry seems to be directed at potentially bad recommendations of the CPAN/CPANPLUS shell - this could be addressed by PAUSE supporting generations in the future (near or far), or it may have to wait until perl6, but from the sounds of things, nothing along these lines will be probably be done in the near term (ie, the next few months); even if Autrijus comes up with a workable proposal in the next month, implementing this, on PAUSE or elsewhere, would take some more time (especially given Andreas', and others', views on this), and then it would be longer to get workable clients out there. Although this may not be the best time to raise this, the strong opinions being expressed, plus the shortness of time on the part of the many of us, perhaps we could look at what would be involved to move the modules in the mp2 core so as not to conflict with mp1. If I counted right, there's not that many: Apache::Log Apache::PerlSections Apache::Resource Apache::SizeLimit Apache::Status Apache::URI Apache::Util Putting aside for the moment the relationship of these to their mp1 counterparts, it shouldn't be too hard to come up with alternate, descriptive names, either in an Apache2::* or ModPerl::* namespace, or perhaps just something different under Apache:: (eg, Apache::Utility). The question of mod_perl.pm itself is different. In the mp2 distribution, in a sense this is used to "brand" the whole package - give it a version, and a pod NAME and description. Although I see Stas' argument about not having a mod_perl.pm and mod_perl2.pm in the same package, what about just renaming mod_perl.pm to mod_perl2.pm? And in keeping with the use of mod_perl.pm to give an abstract that search.cpan.org can use for the mod_perl distribution, renaming the mp2 distribution itself to mod_perl2. If one sees the use of mod_perl.pm as just representing the package, then calling it mod_perl2.pm may not be too unnatural, given that Apache1 modules are fundamentally different from Apache2 modules. There's at least two questions that immediately arise with this. The first - how much physical work would it be to do this renaming? Quite a bit, I imagine, but a finite amount - I'd be willing to set aside some time in the immediate future to work on this. The bigger issue is how such a change would affect existing 3rd party code that currently uses mp2? This may cause quite a bit of headaches - "legally" I guess one is free to do this, since mp2 isn't officially released yet, but one doesn't want to alientate existing users. I fear, though, that if mp2 gets marginalized, even in the short term, by a (sizeable) segment of the general Perl community, this would be a bigger long-term problem for early adopters. This might not happen, of course, but is it worth the gamble? Perhaps, as a stop-gap measure, one could make up a compatibility layer, similar to Apache::compat, that would assist in the change-over. The question of Apache2.pm then also arises, as, theoretically, if such changes were made, Apache2 wouldn't be needed. A couple of people have mentioned that they like Apache2 just as a way of separating mp1 stuff from mp2 - given this, we could keep Apache2 in there, but make it optional (and, perhaps, recommended in the case of an existing mp1 install). That would make the transition easier, but also satisfy the concerns raised about mp2 *necessarily* breaking existing tools. As Stas has emphasized, doing this to the core modules doesn't address the broader issue to 3rd party modules. It's probably reasonable to assume though that these developers would understand why this was done, given the strong opposition and the desire to have mp2 supported as much as possible in the standard Perl environment. Again, I raise the above not necessarily because it's the best solution within the mp2 environment, but because of the pretty strong opinions expressed on the other side. I'm also, frankly, worried about the wider implications and effects raised about this namespace problem outside of mp2 if we don't do this, and as Adam said, getting into a cycle of outwardly spirallying workarounds to solve yet other problems we haven't anticipated. It may be better, from the point of view of keeping peace within the community, making these changes now, and wait until "official" support for generations is in place (which seems to be acknowledged as a real need, both for mp2 and others), either in perl5 or, perhaps, perl6. And Happy New Year! -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
