On Tue, 2003-03-11 at 21:23, Stas Bekman wrote: [snip]
One problem with the above is if you need to support people who have both mod_perl 1.x and mod_perl 2.x on the same system (maybe in cases where a company or ISP would need to run both side by side to support both versions.) The end user could change the PREFIX with which the module is installed and modify their lib path appropriately, installing twice - once for each version of mod_perl, but I think that is a little rough on the end user. One trick I used which seems to work pretty well for me is to have one main module that points to two different mod_perl version specific modules based on whether we are running in mod_perl 1.x or 2.x. For example (untested):
in Apache::FooBar.pm:
package Apache::FooBar; use vars qw(@ISA); ... if(eval "Apache::exists_config_define('MODPERL2')") { @ISA = qw(Exporter Apache::FooBar2); require Apache::FooBar2; Apache::FooBar2->import; } else { @ISA = qw(Exporter Apache::FooBar1); require Apache::FooBar1; Apache::FooBar1->import; } 1;
in Apache::FooBar2.pm:
package Apache::FooBar2; use vars qw(@ISA @EXPORT); @ISA = qw(Exporter); @EXPORT = qw(handler); ... sub handler { ... } 1;
But it seems that you are delegating the problem of figuring out what module to load to run-time.
That was actually the point of doing it that way. We then have one set of installed modules which can determine their version at run-time, instead of having to install two copies of the module. And since the use only happens once, there shouldn't be a big performance penalty (well, besides any @ISA lookups for inheritance.)
You forget one little thing. That a big chunk of Apache modules are written in XS. So you can't build two different XS versions at the same time. And even if you could, what happens if I had only mod_perl 1 and then added mod_perl 2, after installing module foo? or the other way around? You have to reinstall it for both of them.
We'd rather have one convention which will work for XS and non-XS modules (especially since in the future you want want to turn an non-XS module to have some XS in it).
We have already committed to having mod_perl 2.0 modules to go to Apache2/ subdir and the Makefile.PL will do that automatically in the future (for those systems where mp2 is in Apache2/) so this is not an issue. Since when you start your mod_perl 2.0 you have 'PerlModule Apache2' it'll pick the right version.
Installation wise, let's take Apache::Peek as an example. It includes two difference implemenations for each modperl. So if we want to install it for mp1 we do:
% perl Makefile.PL && make install
For mp2, we do:
% perl -MApache2 Makefile.PL && make install
and that's all you have to do. The run time will pick the right version.
Ok, I'm confused. So you mean that using -MApache2 it would install in the Apache2 directory, then rely on use Apache2; in the conf to make it use the right version (like what is done with the core mod_perl modules?) If so I would tend to agree, this is a better idea than doing it run-time in most cases. You still have to install the module twice, but other than that it would work transparently with two versions of Apache/mod_perl on the box (which is really what I was thinking of before.)
Yes, that's exactly the idea. [...]
Hmm. Not sure that I have any other ideas on this one. Maybe prompt (with a timeout?) in the case where -MApache2 was not used or MOD_PERL2 defined, but both mod_perl 1.x and 2.x are installed? Maybe could also allow a MOD_PERL1 just to avoid the prompt for people installing a bunch of modules on systems with both.
sure, we can prompt when things aren't specified explicitly and we see that Apache2 wasn't loaded.
[...]
But a much cleaner and simpler way is to just check the VERSION:
require mod_perl; if ($mod_perl::VERSION < 1.99) { ... }
It looks that we can make it working without adding version numbers to the package names. We just need to work out a clean methodology, convenient to both developers and users.
For some reason I thought I had tried that and there was a problem with checking that way, but when I went back just now and tried again looks like that works fine. Thanks!
;)
You probably did, what I did first, doing: $mod_perl::VERSION < 2.0 :)
__________________________________________________________________ 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
