httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: apreq-2 patches
Date Mon, 24 Jun 2002 05:12:50 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>Bodo Bellut wrote:
>>>>Patches for current httpd-2.0, httpd-test are available:
>>>Does anyone here have patched modperl2 to include the additional
>>Don't expect this to happen before the destiny of apreq2 is known. If
>>apreq2 becomes a part of httpd-core, 
> 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_ 

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.

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

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

View raw message