Sorry for the delay, I couldn't make it sooner. Stas Bekman <[EMAIL PROTECTED]> [03-11-2004 02:30]: > Radoslaw Zielinski wrote: [...] >> * It messes with @INC, changing the way it should be parsed. >> Originally, if you see $inc_file/Foo/Bar/Baz.pm, you know it's the >> Foo::Bar::Baz perl module. Now, it's Foo::Bar::Baz *unless* Foo >> equals to Apache2. The only other module I know, which does it, is >> Tk; it creates problems with automated dependency generators (at >> least), besides being a hack. > it doesn't.
Well, it (the MP_INST_APACHE2 hack) does: "use Apache2" adds an entry to
@INC and other modules rely on it.
> There is no Apache2::Apache::Server. There is Apache::Server.
> It's just one Apache2/ subdir (like there are many other special subdirs
> in @INC dirs). Shouldn't be too hard to get used to it.
I don't know of any more but Tk's plugin directory.
>> * If the API wouldn't change, there would be no porting problems. Even
>> if mp2 is mostly backward-compatible, mp1 isn't forward-compatible; is
>> it? Now, there is no easy (automateable) way of discovering if the
>> module works with mp1 or mp2, or for which version it was written for.
> 1) It should be documented.
> 2) It should be enforced at compile/run time.
In a perfect case. But -- from my expirience -- it rarely is.
[...]
>> * "use Apache2" isn't mandatory, so (IIRC, when I checked last time)
>> most of the mp-dependent code doesn't do it. To patch, or not to
>> patch? To care, or to drop&forget?
> I know. I agree with that point. We have discussed that one quite a lot of
> time. To sum up those discussions, the reason we don't load it
> automatically is to let users adjust their @INC, before Apache2 is loaded.
> Which is a must in case a user has a local modules installation and has
> mod_perl2 living there.
> This whole issue is moot for users who have moved to mp2 and forgot that
> mp1 ever existed, which will be the case for 99% of users some time after
> 2.0 is released and considered stable.
And what should an average Joe Distributor do while both versions are in
use...?
>> * A sysadmin (or user) without Perl knowledge won't even be able to
>> build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for
>> example), when an installation of mp1 already exists -- requires
>> ripping Makefile.PL with sharpened $EDITOR. Yes, this Makefile.PL
>> can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one
>> of many.
> I'm not following you on this one. What's the problem of passing
> MP_INST_APACHE2=1? You mean they actually need to know that they need to
> type that? But the error message tells them that already.
No. Maybe a "patch" will show it:
--- mod_perl-1.99_15-org/Makefile.PL 2004-08-24 18:33:21.035839248 +0200
+++ mod_perl-1.99_13/Makefile.PL 2004-08-24 18:34:24.406205488 +0200
@@ -151,7 +151,7 @@
error "cannot install mod_perl/$VERSION on top of $vstring",
"use MP_INST_APACHE2=1 option " .
"or to force installation delete:\n $old_modperl_pm";
- exit 1;
+# exit 1;
}
}
}
I want to build without MP_INST_APACHE2 and run make install with
DESTDIR. This is a minor example of problems with "Makefile.PL logic".
Nevermind.
>> * Doug wrote: "xs modules will need Makefile.PL/#ifdef logic to work
>> with both versions". Well, from my expirience, if such a logic works
>> in any not-so-weird case and doesn't require investigation / patching,
>> it's accidental. If you want both mp1 and mp2 on your system, you
>> won't get away without all-the-hacks' know-how.
> From my personal experience, I have separate XS files for each version.
> See Apache::Peek. I don't think it's a good idea to try to support both
> versions in the same XS file. The C API is *totally* different between the
> two generations.
I don't have any XS knowledge, so just guess it would be possible to
write separate "plugins" for both versions (if one wants to support
both).
[...]
>> All these issues boil down to one thing: you can't have mp1 and mp2 with
>> applications for both without using hacks. You aimed for simplicity and
>> backward compatibility, but IMHO the result was reversed in this case.
> Either we are not on the same line or I'm not agreeing with you.
I think the first one. We can eventually come back to it later.
> There are quite a few CPAN modules that deploy that technique. e.g.
> Apache-VMonitor-2.0.
It uses a 5KB Makefile.PL just for figuring the installation path and
dependencies... :-/
> Granted, there are issues with making the process of choosing the right
> generation (for those who have both installed) at build time. My hope
> was/is to have one standard way to handle that.
IMHO sooner mp1 will vanish.
>> How could it be avoided?
>> Full Apache2::* namespace. Apache2::compat::Apache1 could provide
>> Apache::*->Apache2::* aliases for compatible features and define custom
>> Apache::* for the incompatible ones -- both types of applications could
>> work in one interpreter. That would leave place for A2::compat::A3, and
>> maybe for Apache::compat::Apache2. No hacks required.
> If you dig under the hood, it's not simple at all. To start with how are
> you going to handle the fact that no module is loaded by default? And you
> certainly don't want to load 50 modules each coming with .so object, just
[1]
> to support this aliasing feature. Or do you suggest to just alias the
> namespaces?
Maybe I'm missing something. I was thinking about just aliasing the
namespaces.
> Second, quite a few methods have the same API name, but a totally
> different functionality. Please see lib/Apache/compat.pm starting from
> overridable_mp2_api.
> I can't see how the two can coexist.
$ cat MP2/Foo.pm
package MP2::Foo;
sub sf { print shift() . "::same\n"; }
sub df { print shift() . "::different\n"; }
1;
$ cat MP2/compat1.pm
package MP2::compat1;
use MP2::Foo;
BEGIN { $INC{'MP1/Foo.pm'} = __FILE__; }
*MP1::Foo::df = sub { print shift() . "::different_overridden\n"; };
*MP1::Foo::sf = \&MP2::Foo::sf;
1;
$ perl -MMP2::compat1 -MMP1::Foo -we 'MP1::Foo->sf; MP1::Foo->df'
MP1::Foo::same
MP1::Foo::different_overridden
About [1]: if there is too many MP2::Foo's to use() them in MP2::compat1,
then maybe AutoLoader could help:
$ cat MP2/compat1.pm
package MP2::compat1;
use AutoLoader ();
BEGIN { $INC{'MP1/Foo.pm'} = __FILE__; }
*MP1::Foo::AUTOLOAD = \&MP2::compat1::autoload;
sub autoload {
($AUTOLOAD =~ /^MP1::((.+)::.+)$/)
? eval "require MP2::$2"
: die "you murderer, I didn't got here by accident";
die $@ if $@;
*MP1::Foo::df = sub { print shift() . "::different_overridden\n"; };
*MP1::Foo::sf = \&MP2::Foo::sf;
# other aliases go here... this should only be executed once
goto &$AUTOLOAD;
}
1;
...well, maybe in a smarter way. Note, that this allows coexistence of
both mp1 and mp2 applications in one interpreter.
[...]
> One more thing to consider. At the moment 3rd party modules will be
> installed into Apache2/ if mp2 lives there. so if your proposal goes in,
> that means that all CPAN modules will need to have Apache2/ for the mp2
> implementation (in case there are two separate implementations) again
> requiring a compat layer in the case where the user API of those CPAN
> modules (not modperl) hasn't changed).
I think this price is worth the cleaner interface and less hackish
approach.
--
Radosław Zieliński <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]
pgpQ2WspGgycZ.pgp
Description: PGP signature
