On Fri, 25 May 2001, Stas Bekman wrote:

> 
> I'm going to talk about 3 issues here: namespace, prerequisite and CPAN
> listing. All related to a single issue, a smooth move into the next
> generation of mod_perl with as little confusion created as possible.
> 
> =head1 namespace
> 
> I think we've discussed this slightly before, but I wonder whether we want
> to reserve Apache2:: namespace and have all the ported modules to move
> into Apache2:: namespace, so it:
> 
>  -- will not confuse users about whether the modules works with 2.0 only
>  -- force the authors to review their code in order to make it complient
>     with 2.0

i don't want to move everything into an Apache2:: namespace.  many/most of
the modules on cpan should work with 2.0 without any change.  the ones
that will not work are the .xs modules.  one attempt to solve that problem
is already a Makefile.PL option:
INST_APACHE2    Install *.pm relative to Apache2/ directory

then you say 'use Apache2 ()' or 'PerlModule Apache2' which adjusts @INC
to look there first.

> I'm talking mainly about modules like Apache::Filter, Apache::Scoreboard
> and similar which are tightly tied to mod_perl-1.3. I can foresee many
> unncessary question on the list, because people will use wrong versions of
> the modules.

the INST_APACHE2 logic could also be used for newer versions of
Apache::Scoreboard, Apache::Request, etc.  i already hinted in march when
ken raised the issue, Apache::Filter should be named Apache::PerlFilter.
there's still plenty of time to make that transition.  the current
Apache::Filter is obsoleted by 2.0.
 
> The same goes for mod_perl-2.0 core modules. Having Apache2:: and Apache::
> will allow to have both servers under the same /usr/lib/perl5 and will
> allow OS distro to ship both versions and have them non-self-exclusive.

the INST_APACHE2 option solves this, similar to how Perl installs its
modules in a version specific directory.
 
> Another issue is having an unambiguous way to require a correct context
> with something like:
> 
> Apache.pm:
> ----------
> sub require_mod_perl2 { 1; }
> 
> So if in your modules which work only with mod_perl-2.0 you will write:
> 
> Apache::KillerApp:
> ------------------
> use strict;
> Apache::require_mod_perl2();
>
> and if the code is not running under mod_perl, this method will be simple
> not available.
> 
> I prefer to have a standard accepted documented way to do that, rather
> everyone trying to implement their own.
>
> Also it would be nice to add now a method to 1.3 which will be also used
> in 2.0 and allow to retrieve the version number easier than doing re:
> $ENV{MOD_PERL} =~ /2/

we already have 'use mod_perl 2.0'
 
> this or similar technique will allow authors to have their code
> working under 2.0 and 1.3, out of mod_perl. e.g.:
> 
>   if (defined MOD_PERL_VERSION) {
>       if (defined MOD_PERL_VERSION >= 3.0) {
>         # 3.0 specific code
>       } elsif (MOD_PERL_VERSION >= 2.0){
>         # 2.0 specific code
>       } else {
>         # 1.x specific code
>       }
>   } else {
>     # non mod_perl code
>  }

Apache::compat takes care of this for you, at least for differences
between 1.x and 2.0.
 
> (yeah, I do look forward into 3.0. Just like some people are still using
> perl4, while perl6 is under development, there will be still people using
> mod_perl-1.x, when we will talk about mod_perl 3.x.)
> 
> Until now a mere checking of $ENV{MOD_PERL} to figure out whether we are
> in the mod_perl environment was good enough, but not anymore since we have
> to be able to differentiate between 1.x and 2.x now, and using regex on
> $ENV{MOD_PERL} is ugly and error prone.  MOD_PERL_VERSION constant seems
> like a much nicer way to do this.

again, there is already $mod_perl::VERSION which can be used conditionally
if needed.
 
> 
> =head1 CPAN listings
> 
> In any case we will have to start a new list of modules on
> perl.apache.org, and list modules which work with 2.0 (and possibly with
> 1.3).

this should only be needed for modules with xs.  modules like HTML::Mason,
Apache::Dispatch, Apache::Reload, Apache::Motd, Apache::MP3, etc, will
work out-of-the box with 2.0, the only requirement might be to configure:
PerlModule Apache::compat

xs modules will need Makefile.PL/#ifdef logic to work with both versions.
but the applications that use them should not need to know the
difference.  introducing an Apache2:: namespace would require that they
do know the difference.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to