Re: Slashdot | Help Test mod_perl 2 Release Candidates

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

Geoffrey Young wrote:
> 
> 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:stas@xxxxxx.xxx 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