Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of radek@karnet.pl designates
 62.121.128.10 as permitted sender)
Date: Sun, 21 Nov 2004 13:22:55 +0100
From: Radoslaw Zielinski <radek@karnet.pl>
To: dev@perl.apache.org
Subject: Re: [apr] dropping Apache2/ subdir for APR::*
Message-ID: <20041121122255.GB2851@bongo>
Mail-Followup-To: dev@perl.apache.org
References: <40E49C7A.8050605@stason.org> <20041102014104.GA31022@bongo>
 <4187144A.2010503@stason.org> <20041102131554.GA7504@bongo>
 <418834B0.5000401@stason.org> <20041114145109.GA2832@bongo>
 <41978264.6040704@stason.org> <20041119122229.GA3387@bongo>
 <419E5CC5.8000304@stason.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="MfFXiAuoTsnnDAfZ"
Content-Disposition: inline
In-Reply-To: <419E5CC5.8000304@stason.org>
Organization: independent
User-Agent: Mutt/1.5.6i

--MfFXiAuoTsnnDAfZ
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Stas Bekman <stas@stason.org> [19-11-2004 21:51]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <stas@stason.org> [14-11-2004 17:05]:
>>> Radoslaw Zielinski wrote:
>> [...]
>>>>> to support this aliasing feature. Or do you suggest to just alias the=
=20
>>>>> namespaces?
>>>> Maybe I'm missing something.  I was thinking about just aliasing the
>>>> namespaces.
>>> It's a way more complicated than it seems to be at first sight. Search=
=20
>>> the dev list's archives for EazyLife to see some of the problems.
>> Done...  OK, so AUTOLOAD is just a can of worms.
>> But, as the code we're trying to make work already knows which
>> modules does it need to work, we can try a different approach:
>> trap the "use Apache::OldName" calls with a subroutine ref in @INC.
>> Example implementation attached; would this work?
>> I actually don't really like it, as it's a hack, but... I can't see
>> how this could impact on anything.
>> Well, let's see what I've missed now ;-)
> IMHO, it's a waste of time to try to resolve the namespace issue before=
=20
> the API incompability is resolved (which I doubt is possible or shouldn't=
=20
> be even attempted)

Huh?  Resolving the namespace issue just removes the API incompatibility
problem, doesn't it?

[...]
>>> The problem is that mp1 and mp2 aren't fully compatible, and there is n=
o=20
>>> way to make them so 100%, mainly. So you have a problem here. You can't=
=20
>>> run all mp1 and mp2 applications under the same interpreter. Again take=
 a=20
>>> look at lib/Apache/compat.pm %overridable_mp2_api and read:
>>> http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Fu=
nctions_Colliding_with_mod_perl_2_0_API
>> I've seen it before and still don't see a problem, when we have *differe=
nt
>> namespaces*.  I assume, that the compatibility layer is similar (in
>> effect, not necessarily the implementation) to the attached one.

>> Can the problem you're seeing be resolved by (I don't know how to do it
>> mod_perl-wide; maybe a per-VirtualHost/Location directive, telling mp2
>> to return objects blessed into a specific namespace for a given handler?=
):

>>   package handler_for_mp1_partially_ported_to_mp2;
>>   sub handler {
>>   my $r =3D bless shift, 'Apache::RequestRec'; # was Apache2::RequestRec
>>   # same thing with $c or whatever
>>   ...
> Have you read the URL quoted above? The two APIs behave totally different=
=20

Yes, Stas, I have read it.  Several times, actually, to make sure
I haven't left out any unresolvable issues.  I really don't see any.
Could you name it?

> and it's not possible to figure out at run time, which API generation is=
=20
> desired.

=2E..I just don't see an easy way to resolve this one right now, if the
httpd.conf directive option I mentioned earlier is not acceptable /
possible.  But I think I'll figure something out.

> The code you've attached doesn't address that issue and it should be the=
=20
> first issue to tackle. The rest is easier.

[...]

--=20
Rados=B3aw Zieli=F1ski <radek@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

--MfFXiAuoTsnnDAfZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBoIifvesRuUOywuARAoTMAJ9otA9CyPxh6jff5q5bfSqL8aRWyQCg7C1k
ur5mp/6HIP99QrLVM7tnSxM=
=uSSL
-----END PGP SIGNATURE-----

--MfFXiAuoTsnnDAfZ--