httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [multi-env] perl glue implications
Date Thu, 03 Feb 2005 02:22:35 GMT
Stas Bekman <stas@stason.org> writes:

> Joe Schaefer wrote:

[...]

>> What I think this will bubble up into, from the perl glue standpoint,
>> is a new barebones APR:: heirarchy that might work like so
>>
>>   my $req = APR::Request->new($r, MODULE => "Apache2"); # apreq_handle_t
>
> which should probably be abstracted into:
>
>    my $req = Apache2::Request->new($r);
>
> with Apache2::Request being a subclass (or Apache::Request, whatever
> it is). 

Actually I'm thinking of APR::Request as being an analog of
DBI.pm, and the MODULE attribute determines the helper (DBD-like) 
class.  Here an entire driver class might not even be 
necessary though, since apreq will only need a single 
C function (an apreq_handle_t* constructor) from the 
helper module.

I don't object to a tiny "Apache2::Request" wrapper class
which just overrides APR::Request::new, but I also don't yet 
see the point of doing that. One thing I really don't like 
about that idea, is that will create source code incompatibilities 
for perl apps which otherwise won't care about the MODULE setting.

-- 
Joe Schaefer


Mime
View raw message