httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [PATCH] first snapshot of my "let's kill void*env" patch
Date Sun, 09 Jan 2005 23:11:00 GMT
Max Kellermann <> writes:


> I believe the perl API may stay compatible, because the perl
> constructor can 'ref' a pointer, and can dynamically load new
> packages if required. 

Or optional functions from apr.  Haven't thought about it
yet, but I'm sure it's doable from that standpoint.

> Although I'd be luckier with the following constructor:
>  my $apreq = new Apache::Request(Apache2 => $r);
>  my $apreq = new Apache::Request(CGI => $pool);

Right. That sort of highlights the problem we've always had here.
Trying to be (nearly) back-compat with the 1.x API for Apache::Request
screws us;  the perl glue should be using a delegation model (ie helper class)
instead of inheritance, but unless mp2 decides to change its API,
we're stuck trying to shoehorn all this into an ISA relationship. 

> An Apache::RequestRec pointer is clear, but an APR::Pool may be
> ambiguous as soon as there are more env modules. Passing an 
> APR::Pool sounds too common for an env module... nothing in APR::Pool
> tells me instantly "hey, the caller wants CGI".

Totally agree, but there wasn't any other obvious candidates
to fill the (void *)env ;-).

> Another idea: make the first "env module name" optional, and let the
> Apache::Request constructor guess (just like it's now). Check
> $ENV{GATEWAY_INTERFACE} if it's ambigous. That's a hack, but the
> caller chooses if he's using the hacked constructor (for the quickie
> script) or the deterministic one with env module name.
> The one thing which will go away is the "env" method, looks like a
> superfluous method anyway, isn't it?

Too early to say; right now we need env() to maintain some of
the internal ISA hacks.

Joe Schaefer

View raw message