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 11:48:07 GMT
Max Kellermann <max@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


Mime
View raw message