You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2005/02/03 02:40:36 UTC
Re: [multi-env] perl glue implications
Joe Schaefer wrote:
[...]
> The implications for the perl glue will all stem from this
> fundamental change in the C API:
[...]
> ultimate goal: apreq_handle_t *req = apreq_handle_apache2(r);
>
>
> So all requests for parsed data will go through the common apreq_handle_t,
> instead of having separate structs for cookies and params. 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).
> my $jar = $req->jar(); # an APR::Table-derived object
> my $foo_cookie = $jar->{foo}; # an APR::Cookie, wraps apreq_cookie_t
> $foo_cookie->expires(200); # APR::Cookie::expires method
> $foo_cookie->bake($req); # bake the cookie, $req arg needed now
>
> my @foo_uploads = grep {$_->bb} $req->body("foo"); # APR::Param objs
> my $foo_filename = "$foo_uploads[0]"; # same as $foo_params[0]->value
> my $foo_value = $req->param("foo"); # ordinary (unblessed) scalar
>
>
> The API defects in trunk's Apache::Cookie and Apache::Request are IMO
> best addressed by creating those modules out of these new bareboned
> APR:: classes. That way the new stuff goes into the new APR:: modules,
> and our old Apache::* modules can aim towards better 1.x compatibility.
>
> At least that's how I see things falling into place on the perl side,
> once the multi-env C API stabilizes.
Sounds good to me.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [multi-env] perl glue implications
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Max Kellermann <ma...@duempel.org> writes:
[...]
> I prefer Stas' idea of an Apache2::Request class, CGI::Request etc.
>
> DBI.pm is a single constructor for all database drivers for a reason
> which is not relevant for us: they want software to connect to any
> database only by replacing the connect string (from a config file?).
>
> At the time users of apreq are initializing an APR::Request object,
> they can't write abstract code anyways - either they're in a mod_perl
> script, then they have to pass the RequestRec, or they're in a CGI
> script, then it's an APR::Pool. After the APR::Request derivative is
> created, they are free to pass that to abstract functions.
>
> The arguments are the same as in the C API.
+1.
> btw. I'm unsure if the abstract base class should be named
> APR::Request. It's not part of APR, it only uses APR.
I don't see the harm in using APR::. Other third-party
APR:: apps will wind up in APR:: on CPAN, and I really
don't see the apr guys ever wanting to write a competing
request/cookie library. I believe it's more likely that
apreq could become an apr subproject, especially if httpd
decides they want to include mod_apreq in their distro.
So from that standpoint, I prefer we used the APR:: prefix.
> Apreq::Request? Apreq::Handle?
We've tossed around on a few of these namespace questions
before, but nothing stuck. Personally I'm more concerned
about how to carve up the API in trunk's Apache::Request.
I think we can remove all its non-mod_perl modes, but we
have to keep it being an Apache::RequestRec -derived class.
And so we must remove the defective args() and status() methods.
At that point body() doesn't make much sense anymore either,
and we still have to deal with the fact that Apache::Request
users expect to have a modifiable parameter table to
work with (which args and body will no longer provide
on the C level). So I think trunk's Apache::Request will
wind up looking a lot more like the 1.x API; in particular
instance() and new() will probably be different subs again.
Anyway, I suppose we'll cross these bridges once we
encounter them. I just wanted to start discussing
them now, so we don't paint ourselves into a corner
with the coming C API changes.
--
Joe Schaefer
Re: [multi-env] perl glue implications
Posted by Max Kellermann <ma...@duempel.org>.
On 2005/02/03 03:22, Joe Schaefer <jo...@sunstarsys.com> wrote:
> > 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 prefer Stas' idea of an Apache2::Request class, CGI::Request etc.
DBI.pm is a single constructor for all database drivers for a reason
which is not relevant for us: they want software to connect to any
database only by replacing the connect string (from a config file?).
At the time users of apreq are initializing an APR::Request object,
they can't write abstract code anyways - either they're in a mod_perl
script, then they have to pass the RequestRec, or they're in a CGI
script, then it's an APR::Pool. After the APR::Request derivative is
created, they are free to pass that to abstract functions.
The arguments are the same as in the C API.
btw. I'm unsure if the abstract base class should be named
APR::Request. It's not part of APR, it only uses APR. Other ideas?
Apreq::Request? Apreq::Handle?
Max
Re: [multi-env] perl glue implications
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>Stas Bekman <st...@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?
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
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [multi-env] perl glue implications
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> Stas Bekman <st...@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
Re: [multi-env] perl glue implications
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@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