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 Thu, 27 Jun 2002 06:28:57 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>Joe Schaefer wrote:
> [...]
>>>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?
>>You are inviting too many troubles:
>>- What if certain platforms don't support DSO or for some reason are 
>>required to compile statically.
> Then modperl and moddtcl have a similar problem; either way you need
> to rebuild httpd.

My point is that it doesn't make the installation process any easier. 
Quite the opposite.

>>- What if a distro didn't supply the DSO of apreq, and the user has no 
>>ability to build/install it himself (think ISPs)
> Then their vendor-supplied mod_perl binary won't work, since it failed 
> to compile w/o apreq pre-installed :-)

What if only apache is installed?

Here is another problem: How do you upgrade to a newer version of apreq? 
If it gets released with httpd, it's obvious, if not, it's a problem. 
You have a new C code base for apreq, which will require a release of 
the new mod_perl.

>>- Currently mod_perl will be able to build the glue only if everything 
>>is available to him (apr, apr-util, ap, apreq). I don't think currently 
>>it can cope with optional core parts. I guess this can change though.
> It would help if the process by which mod_perl generated the glue were 
> documented, or at least explained on some level.  Is it? And if so, 
> where? (I've tried looking more than once.)  Tinkering minds need to
> know :-)

Well, it's documented partially at
but it doesn't change anything.

>>- the build is going to be much more complicated if you want it to be a 
>>separate package as you cannot re-use httpd build setup as we do it now. 
>>You will have to duplicate lots of things and keep them in sync and 
>>worry about all cross-platforms things.
> Isn't that what apxs is for, so an extension module author has access 
> to the httpd setup?  I don't how apache's libtool figures into apxs, 
> though.  Is that the problem, that we'd need to bundle our own libtool
> like we do now?  I agree *that* would be a very bad thing, but it seems
> like the other "optional" modules bundled with httpd (mod_proxy, 
> mod_rewrite, etc.) don't have a problem.

apxs doesn't work on win32.

>>Well, Doug is doing most of the developing and I'm doing a bit. That's 
>>it, so no surprises here. Doug said that he would love to see apreq be a 
>>part of httpd-core, so here I'm pursuing that idea :)
> I wasn't aware of Doug's opinion on apreq; sorry about that.

I cannot understand one thing. Why are we trying to argue in the 
direction of keeping it as a separate package, where we probably need to 
think of undeniable arguments why httpd-core wants to absorb apreq :)

Seriously, unless apreq doesn't change and supplies both C and Perl APIs 
in itself, I think we are looking for a lot of trouble if we keep it as 
a separate package. I guess this is fine too, only the apps relying on 
certain functionalities previously available in mod_perl now will 
require Apache::Request.

So I suggest the following roadmap: let's try to talk to httpd people to 
get apreq into the core. If we fail, forget mod_perl's build system and 
do the Perl glue the old manual XS way, which won't be bundled with 
mod_perl. I think these are the only 2 options that will be good for the 
final user and those who support those users. Any other options seem to 
me as inviting troubles.

>>>Let's try to come to some consensus about the status of the API, 
>>>and how people think apreq should be bundled with httpd.
>>To me it looks fine, but I don't have any C-level uses for it, so I'm 
>>the right person to judge.
>>I doubt we are going to get any more feedback here. I guess most of the 
>>users are on the mod_perl side, and they use the Perl API, which we 
>>don't discuss now. Tcl users use it, no? Should we ask for feedback at 
>>their mailing list?
> It would be nice to know how libapreq-1.0 is currently bundled with
> mod_dtcl, and how moving the C API into the core would make life
> better for the Tcl folks.


> Maybe David can enlighten us here?

is David on this list?

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

View raw message