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 Thu, 27 Jun 2002 04:23:49 GMT
Stas Bekman <stas@stason.org> 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.

> - 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 :-)

> - 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 :-)

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

[...]

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

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

-- 
Joe Schaefer

Mime
View raw message