Re: Slashdot | Help Test mod_perl 2 Release Candidates

[prev] [thread] [next] [Date index for 2004/12/28]

From: Geoffrey Young
Subject: Re: Slashdot | Help Test mod_perl 2 Release Candidates
Date: 01:21 on 28 Dec 2004

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.

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

--Geoff

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

(message missing)

Re: Slashdot | Help Test mod_perl 2 Release Candidates
merlyn (Randal L. Schwartz) 20:34 on 26 Dec 2004

Re: Slashdot | Help Test mod_perl 2 Release Candidates
merlyn (Randal L. Schwartz) 15:09 on 27 Dec 2004

Re: Slashdot | Help Test mod_perl 2 Release Candidates
Geoffrey Young 01:21 on 28 Dec 2004

About putting the blame on other shoulders
Andreas J Koenig 14:28 on 28 Dec 2004

Re: About putting the blame on other shoulders
Stas Bekman 15:01 on 28 Dec 2004

Re: About putting the blame on other shoulders
Stas Bekman 15:54 on 28 Dec 2004

Re: About putting the blame on other shoulders
Andreas J Koenig 16:11 on 28 Dec 2004

Re: About putting the blame on other shoulders
Issac Goldstand 16:11 on 28 Dec 2004

Re: About putting the blame on other shoulders
Stas Bekman 16:27 on 28 Dec 2004

Re: About putting the blame on other shoulders
merlyn (Randal L. Schwartz) 16:43 on 28 Dec 2004

Re: About putting the blame on other shoulders
Issac Goldstand 16:58 on 28 Dec 2004

Re: About putting the blame on other shoulders
merlyn (Randal L. Schwartz) 17:09 on 28 Dec 2004

Re: About putting the blame on other shoulders
Issac Goldstand 17:30 on 28 Dec 2004

Re: About putting the blame on other shoulders
David Nicol 07:01 on 30 Dec 2004

Generated at 12:16 on 16 Jan 2005 by mariachi v0.52