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 03:11:21 GMT
Joe Schaefer <joe+gmane@sunstarsys.com> writes:

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

Hmm, rereading what's actually written above, maybe thinking
of APR::Request as a class with a "virtual" constructor
(ie no APR::Request::new() sub) is a better idea than
what I first proposed.

Is that more or less what you have in mind Stas?

-- 
Joe Schaefer


Mime
View raw message