httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [multi-env] perl glue implications
Date Thu, 03 Feb 2005 04:06:11 GMT
Joe Schaefer wrote:
> Joe Schaefer <> writes:
>>Stas Bekman <> 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
>>, 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?

Either way works for me.

All I was suggesting is to allow the users to type less. So this of course 
can be done later on and doesn't impede the APR::Request design.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message