perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] taking a step back?
Date Sat, 01 Jan 2005 16:24:49 GMT
Randy Kobes wrote:
> 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::*

-1 to embedding numbers in API

> or ModPerl::* namespace, or perhaps just something different
> under Apache:: (eg, Apache::Utility).

That's wrong, Randy. What you gonna do when mp2.2 is released, which may 
happen any moment, now that Apache 2.2 is getting ready for its release. 
Rename those again? And again for 2.4? ...

I can see s/Apache/ModPerl/ for:


since those aren't Apache API really, so they could be moved like Registry 
modules did. Apache::Reload is another one.

These are Aapache API:


and can't be moved to ModPerl::.

> 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.


mp2.2 will have

Don't forget that you will need to rename as well is a part of the modperl API.'s API didn't change, 
so there is no logical reason to change that.

> 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.

I say that mp2-gets-marginalized-fear talk is BS and FUD.

> 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.

The other side doesn't understand the problem and you can safely ignore 
them. They are perfectly logical and correct to say the things regarding 
the perl modules they are used to. But they don't understand that mod_perl 
is 10 times more complex and different from what they are used to deal 
with, no matter how many hundreds of CPAN modules they have released so far.

I say let it go, this is a futile battle, it's useless trying to spend any 
more time to convince that other side that they dig in the wrong place. 
The amount of time people have spent so far trying to convince us that we 
are wrong, could have been used to already implement the required changes 
in PAUSE and CPAN. But no, people prefer to talk...

> And Happy New Year!

Happy New Year.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

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

View raw message