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 18:29:17 +0100
From: Radoslaw Zielinski <radek@karnet.pl>
To: dev@perl.apache.org
Subject: Re: [apr] dropping Apache2/ subdir for APR::*
Message-ID: <20041121172917.GB31756@bongo>
Mail-Followup-To: dev@perl.apache.org
References: <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>
 <20041121122255.GB2851@bongo> <41A0C6EF.3090504@stason.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx"
Content-Disposition: inline
In-Reply-To: <41A0C6EF.3090504@stason.org>
Organization: independent
User-Agent: Mutt/1.5.6i

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

Stas Bekman <stas@stason.org> [21-11-2004 17:48]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <stas@stason.org> [19-11-2004 21:51]:
[...]
>>> 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?
> How so? IMHO, it's totally unrelated. If you have a function foo() which=
=20
> under both versions accepts the same amount of arguments, which are=20
> totally different, and does a completely different thing and returns=20
> different things as explained here:
> http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Func=
tions_Colliding_with_mod_perl_2_0_API
> how resolving the namespace issue is going to resolve that issue?

Simply: we don't have function foo(), we have methods Apache2::*::foo()
and Apache::*::foo() (the second one introduced by the compat layer).
If the object $c, mentioned in the URL above is blessed to
Apache::Connection (or whatever class it is), $c->local_addr returns a
SOCKADDR_IN object; if it's Apache2::Connection (or whatever), we get
APR::SocketAddr.

The trick is in [1].

>>> Have you read the URL quoted above? The two APIs behave totally differe=
nt=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?
> Great. So do we agree that there is an issue which is a showstopper for=
=20
> the rest of the suggestion? (see above)

No, we don't.  As above.

> Moreover there are APIs which don't exist anymore and for some of them=20
> it's not possible to implement for backword compatibility.

Oh well, then forget them.  There is no such thing as a perfect compat
layer.

>>> and it's not possible to figure out at run time, which API generation i=
s=20
>>> desired.
>> ...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.
> sorry, Radoslaw, I'm not sure which directive are you talking about. coul=
d=20
> you please quote the relevant part of your suggestoin?

[1]  The problem is to tell mod_perl's internals, that it should return
Apache2::* objects for handlers ported to mp2 and Apache::* for these,
which are not ready.  I thought about using a per-<VirtualHost> or
<Location> directive in httpd.conf.  By objects I mean for example $r,
which PerlHandler::handler() gets as its first argument.

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

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

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

iD8DBQFBoNBtvesRuUOywuARAiJCAJ4vGhAmB43NiCPuB7HvOvPhIXT6lQCfcV4e
DBwe87It1CZEIP+86zcjb2s=
=FFkR
-----END PGP SIGNATURE-----

--aM3YZ0Iwxop3KEKx--