perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From K Tensmeyer <>
Subject Re: [mp2] taking a step back?
Date Sat, 01 Jan 2005 18:59:06 GMT
On Saturday 01 January 2005 10:24 am, Stas Bekman wrote:
> Randy Kobes wrote:
> [...]

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

  a valid issue.
  While a reasonable solution can be found, the preferable methods will be the
ones that seem intuitively obvious, and will work "out of the box" for most   

> I can see s/Apache/ModPerl/ for:
> Apache::PerlSections
> Apache::Resource
> Apache::SizeLimit
> Apache::Status
> 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:
> Apache::URI
> Apache::Util
> Apache::Log
> and can't be moved to ModPerl::.

   and we have assumptions as to functionality. ( they should have similary 
functions to Apache 1.3.x related modules

> > 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.
> -1
> mp2.2 will have
> Don't forget that you will need to rename as well

   this is getting more and more complicated.

     the two major side issues are 
       1)  running multiple instances/versions of modperl
       2)  finding the "right" modules in CPAN to work with the targeted 

     thanks to the ongoing discussions I understand a little more of the 
issues w/regards to  CPAN/Pause, but I don't see any quick solution.

    One of the common tools/methods used in testing software on the user end 
(not the modperl side itself)  is to map different configurtion options based 
on a logical path.   so and can refere to the same file but 
with different configuration parameters and specified in the httpd.conf file.

  While it won't work were API's have changed, it would be 'nice' if similar 
approaches could work  with mp1, mp2 and mp2.2.X without changing the perl 
modules (or scripts).  Which leaves only the <Perl> </Perl> segments for 
making the specifications.   Would it make sense to have some  thing which 
effects the local @INC (and have it determine which support modules got 
   Is there a functional modperl equivalent for Perl "require 5.6.1;" ?
  so that a reference to could be set to the 1.99.X version or the 
2.1.X version and have it find the right piece of the pie.

 I guess I don't understand enough of the dependency resolution magic to see a 
simple solution here.

    about the only part of Schwartz's diatribe that resonated with me is the 
assumption that most of the masses testing MP2 would assume that it would be 
a drop in replacement for MP1 and would be a simple upgrade.
   making it clear to people that it requires major changes to implement and 
does not simply replace mp1 as apart of the basic communication will remove a 
lot of the silly stuff that would otherwise overwhelm basic bug reporting.

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

   <agreed>  but, getting people to agree before code get's engraven will save 
redoing bad changes several times. I doubt if anyone will stand up and fix 
the PAUSE/CPAN issue, because it won't be their ox that is being gored. 
(which is usually why people are willing to change code other than their 

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

View raw message