httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <...@sunstarsys.com>
Subject Re: apreq-2 patches
Date Wed, 26 Jun 2002 16:48:35 GMT
Stas Bekman <stas@stason.org> writes:

> Joe Schaefer wrote:
>
> > I don't know exactly what you mean by "part of http-core", but my 
> > hope is that apreq is bundled with apache-2 in a way similar to the 
> > patch.  AFAICT, this is just like the (optional) expat interface 
> > built into apache-1.
> 
> It cannot be optional. If it was OK to have it optional it would simply 
> stay a separate package. The only way I can see is having it as a part 
> of core, meaning that it's *always* compiled in. Most likely the only 
> way it'll be accepted by httpd if httpd will have a use of it (e.g. some 
> local implementations of certain methods to be replaced with apreq_ 
> methods).

It seems possible that if apreq were bundled as an optional module,
it could still be a prerequisite for mod_perl and mod_dtcl.  Being a
module, it could be installed as a DSO, so it wouldn't require httpd
to be rebuilt if it were "missing", right?

> Why it cannot be optional? Because currently mod_perl 2.0 doesn't have 
> interfaces like $r->args in the list context, meaning that if 
> Apache::Request is not available the code needing these APIs won't work. 
> Remember that in mod_perl 1.0, we did have this and similar APIs in the 
> mod_perl core and Apache::Request was optional. 2.0 won't supply such if 
> Apache::Request won't become a part of it.

Wow- I didn't realize that, and under the circumstances I'm a bit
surprised that none of the modperl developers (besides yourself) have 
expressed any interest in the fate of apreq.

> >>the "bindings" will be in the modperl-core.
> > 
> > 
> > I am skeptical about mod_perl being able to generate context-sensitive 
> > perl subs like Apache::Request::param.  I'm sure we'll need to write 
> > *something* (actually I expect we'll need to rewrite *most* of
> > Request.xs and Cookie.xs).
> 
> Of course we will need to write a bit of a glue code, but just a bit. 
> Most of the glue code can be autogenerated. Look at how mod_perl 2.0 
> generates all the API for APR and Apache.
> 
> Of course if you decide to keep Apache::Request as a separate package, 
> that sucks. Because the module authors cannot rely on Apache::Request 
> being installed on the user's system, and need to use some slow 
> interfaces like CGI.pm and CGI::Cookie.
> 
> If apreq2 becomes a part of the httpd core, it becomes a part of the 
> mod_perl core (and ceases to exists as a separate package). When this 
> happens it benefits from the mod_perl build system (which at this moment 
> cannot be used outside mod_perl) and module authors can rely on the 
> Apache::Request functionality being always available.
> 
> Not talking about the fact that distributing a package as a patch, 
> sounds as a bad idea to me.

Agreed, Apache::Request really should be a part of mod_perl 
(still disagree about "apreq in the core" though).  

Let's try to come to some consensus about the status of the API, 
and how people think apreq should be bundled with httpd.

-- 
Joe Schaefer

Mime
View raw message