perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <a...@phase-n.com>
Subject Re: Assumption of guilt
Date Fri, 31 Dec 2004 01:46:13 GMT
> Look, there are already a few packages on CPAN that 
> apparently run well on either architecture, and we won't be 
> asking those people to maintain (and interface with) multiple 
> packages that are otherwise functionally identical.

But they don't HAVE to maintain multiple packages. If _their_ API stays 
unchanged and can work quite happily with either, there is no reason for 
them to change.

Or if they want to move to the new API they can do what a number of perl 
modules have done over the years when they moved API and put a 
placeholder in the old namespace (installed from the same package).

package Apache::MyModule;

(do the main work)

1;



package Apache2::MyModule;

use base 'Apache::MyModule';

1;



... or if they want they _can_ maintain two different packages, give the 
old one to someone and call it "legacy", and do the new one differently.

There are a number of known solutions for the issues brought up by 
moving to a new namespace. We've done this stuff before and it's a 
solved problem.

To pick a few examples, you can have two different versions of the 
module and load them in at compile-time. You can work out which to use 
by switching between the two at run-time on a per-method-call basis. (As 
happens in some filesystem code).

If you like I could modify a couple of existing third-party Apache 
modules to show a couple of ways that this could be done sanely.

While I understand you have tried to keep the APIs similar, the problem 
remains that it is simply unworkable to maintain and support multiple 
different APIs within a set of arbitrary version ranges within a single 
module name.

If you'll forgive me for putting a name on the concept, I'll refer to it 
as "API overloading", where API overloading is defined as "supporting 
multiple production/stable/current, but incompatible, APIs within a 
single namespace".

API overloading simply will not work, as I demonstrated earlier. While 
you can reach the point where you can load the code, that's all you can 
really do without gradually replacing every other system and every other 
tool throughout all of perl, until you reach the point where what you 
have is mod_mp2perl.

Having had another day to look into the code, I suspect it can also be 
shown that the feature/mechanism you are using to implement API 
overloading is mutually exclusive to all other modules using the mechanism.

Only one API in any program is ever able to use the trick the Apache2.pm 
uses, unless you were to wrap up the entire of @INC into an anonymous 
CODE reference which redirects into a package that implements your new 
module resolver. You would probably also have to write a new 
Apache2/lib.pm instead of lib.pm, and/or turn @INC a tied array that 
lets all other perl modules treat it normally.

As I said, there are workarounds that can make this happen, but the 
number required just keeps increasing and increasing until you have 
forked or replaced every major system in perl.

The maintenance load of patches your version of lib.pm whenever the core 
lib.pm changes, or doing this for mp2doc, mp2cpan, mp2man, mp2pod2man, 
etc etc etc would be unbelievable.

--------------------------------------

Now, if you assume that API overloading in general is simply inviable, 
you are left with the same situation as every other perl module.

You either move to a new name, or you document that you are immediately 
and irrevocably end-of-life'ing all previous versions of that module.

These are your only two viable options that I can see...

I simply cannot believe that you would want to immediately make 5/6ths 
of your entire user base redundant and make them upgrade immediately. I 
know that you have tried to provide an upgrade path, but unfortunately 
that is what will happen.

If I were to speculate, the only alternative I can see if that mod_perl 
2.0 was to be locked out of the indexer as stas suggested earlier.

The problem will be that mod_perl 2.0 and any other Apache:: third party 
modules that move over to the new API, are _ALL_ going to have to be 
locked out, to prevent mod_perl 1 installations "upgrading" to a newer 
version that is fatally incompatible.

This is not going to be for a year, it's going to be indefinitely. Or 
more likely for 5-10 years, until the mod_perl 1 userbase has largely 
completed porting over. Or possibly until perl 6 is released.

---------------------------------------

But I'm starting to go on and on again. Stas has said he will be 
responding shortly, once he has dealt with some bugs. We can wait for 
him before continuing.

Adam

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


Mime
View raw message