httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: apreq-2 patches
Date Thu, 27 Jun 2002 03:35:25 GMT
Joe Schaefer wrote:
> 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?

You are inviting too many troubles:

- What if certain platforms don't support DSO or for some reason are 
required to compile statically.

- What if a distro didn't supply the DSO of apreq, and the user has no 
ability to build/install it himself (think ISPs)

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

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

probably more reasons to worry about, I still didn't have enough coffee.

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

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

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

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message