perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <>
Subject [mp2] taking a step back?
Date Sat, 01 Jan 2005 03:52:23 GMT
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:


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 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
and in the same package, what about just
renaming to And in keeping with
the use of to give an abstract that can use for the mod_perl distribution,
renaming the mp2 distribution itself to mod_perl2. If one
sees the use of as just representing the
package, then calling it 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

The question of 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,

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

View raw message