perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From K Tensmeyer <kermit.tensme...@verizon.net>
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   
people.

> 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 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.
>
> -1
          yep..
>
> mp2.2 will have mod_perl2_2.pm?
>
> Don't forget that you will need to rename APR.pm 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 
software.

     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  http://mysite.block.org/config1/applicationA and 
http://mysite.block.org/config3/applicationA 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 
loaded?)
   Is there a functional modperl equivalent for Perl "require 5.6.1;" ?
  so that a reference to APR.pm 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.


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

 </hmmm>
>
> 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 
own.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message