perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Wed, 03 Nov 2004 01:30:24 GMT
Radoslaw Zielinski wrote:
> ...but now I did some homework, and -- suprisingly -- you knew them:
> <>.
> Then Doug came up with the hackish approach:
> <>.
> 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/, 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 

Second, quite a few methods have the same API name, but a totally 
different functionality. Please see lib/Apache/ starting from 

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     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message