httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Kellermann <...@duempel.org>
Subject Re: [PATCH] first snapshot of my "let's kill void*env" patch
Date Sun, 09 Jan 2005 22:35:25 GMT
On 2005/01/09 23:06, Joe Schaefer <joe+gmane@sunstarsys.com> wrote:
> if we're able to extend it into the perl glue without losing Win32
> portability, I'll be +1 on it.

I have written many many lines perl and C in my life, but I have never
combined the two - I need to learn that first. I had a first look at
the glue on friday.

I believe the perl API may stay compatible, because the perl
constructor can 'ref' a pointer, and can dynamically load new packages
if required. Although I'd be luckier with the following constructor:

 my $apreq = new Apache::Request(Apache2 => $r);
 my $apreq = new Apache::Request(CGI => $pool);

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".

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?

Max


Mime
View raw message