Radoslaw Zielinski wrote: [...]
...but now I did some homework, and -- suprisingly -- you knew them: <http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99075968309515&w=2>. Then Doug came up with the hackish approach: <http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99076168913061&w=2>.
Now why is it wrong?
* It relies upon changed @INC. Another thing to be remembered about. * 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. 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.
* 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.
* You can't use both mp1 and mp2 applications in scope of a single "PerlModule Apache::compat" (if the mp2 application is Apache::compat incompatible).
And you certainly shouldn't do that, if I understood correctly what you have meant.
* "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.
* 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.
* 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.
* ...well, I don't remember more right now.
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. There are quite a few CPAN modules that deploy that technique. e.g. Apache-VMonitor-2.0.
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.
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 to support this aliasing feature. Or do you suggest to just alias 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.
About the [1] mess: I don't see any. If you'd like your application to work with both, you'd write for mp1 and require the appropiate compat module to be loaded. If something's missing, we'll see it at the compilation stage, without wondering "does this method I'm using in this rarely triggered case do the same thing under mp2 with Apache::compat?".
unfortunately there is no compat module which handles everything. some parts aren't feasible (e.g. see my above comment wrt to overridable_mp2_api.
I just hope I don't repeat something already discussed.
I don't recall this idea being mentioned. So it's probably a new one. Please correct me if I'm wrong.
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).
-- __________________________________________________________________ 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]
