Perrin Harkins wrote:
however, it's not as simple as renaming everything Apache2::*. why? it just doesn't scale well. for example, there are _already_ compat issues between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would need Apache2::* for modules that use the Apache 2.0 API and Apache2.2::* for those that use the 2.2 API. then perhaps Apache3::* someday, etc...
I don't really see what the problem is with that. C libraries seem to do
it that way without too much trouble. What would be the harm in having
Apache2_2:: and Apache3:: and Apache27:: etc.? It's no worse than saying
"I want Apache::Foo, but from the 2.2 distribution."
well, I agree that doing it that way isn't the _worst_ thing that could happen, but I can't help but feel that perl can do better.
In fact Perrin gave a perfect counter-example, while looking for an example. The fact is C libraries *do not* embed version numbers in their API. The API always stays the same (at least for most libs that I know). It only differentiates different releases by using a different .so|.a name. But it doesn't change the API. The problem that perl does not have a solution for this problem, and we have no other choice but use an Apache2/ workaround. Perl has been evolving for more than 10 years, and one day it'll have a built-in solution for this filesystem collision problem.
And where do C libs install their header files? Each in a separate sub-directory:
/usr/include/db1/ /usr/include/db2/ etc
Moreover this is another perfect example about Randals problem with manpages. When you have more than one generation of the same library (.e.g libdb) do you have more than one set of manpages for each generation? No, you don't. You can have only one manpage (e.g. for dbopen(3)). If you want to have more than one version you need to install the manpages in a hidden location and manipulate the MANPATH to point there.
Is the fear that it will be too confusing to users?
I think that is part of it. imagine a module like Apache::Cookie, which is able to trivially support both mp1 and mp2 in the same distribution. would mp2 users never find it because it isn't under Apache2::Cookie? would apache 2.2 users think it didn't work for them? I just can't see a naming scheme like that being anything but confusing for a CPAN namespace that is as large as ours.
of course, the issue of multiple top-level namespaces also feels kinda wrong. if we were to go this route I might feel better if we stuck to an Apache::2_0::Foo type convention. but it still feels suboptimal.
I was tossing around the idea of a new "api version" global. something like
our $API_VERSION = 2.2;
and then
$class->VERSION(2.2);
then CPAN (and related tools) might default to API version "1.0" for no $VERSION, but understand what we mean when the same module has "1.0", "1.1", "2.2" and "2.3" uploads on CPAN (namely that "1.1" and "2.3" become the dominant releases).
sure, there are issues around this, like what to do when the last upload Foo-Bar-0.8 with API version "1.3" while the current one is Foo-Bar-0.9 with API version "1.2", and it (by itself) doesn't solve the @INC issue, but...
No, Geoff, this should be accomplished by a standard mechanism of:
META.yml: generation: 2.2
META.yml is there for exactly this reason. Unless I've misunderstood what you are talking about.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
