joe_schaefer at yahoo
Apr 26, 2012, 11:18 PM
Post #3 of 4
(180 views)
Permalink
|
>________________________________
> From: Issac Goldstand <margol [at] beamartyr>
>To: dev [at] httpd
>Sent: Friday, April 27, 2012 1:55 AM
>Subject: Re: packaging libapreq2 as a dependency
>
>
>On 27/04/2012 05:12, Joe Schaefer wrote:
>Now that some time has passed since Philip brought
>>apreq2 into trunk it's probably a good time to discuss
>>how best to incorporate it into httpd itself. Right
>>now the library files are in server/ which basically
>>means we're internally compiling libapreq2 into httpd.
>>
>>
>>Personally I'd prefer to see libapreq2 bundled as an
>>upstream dependency, ie put the library into an associated
>>deps package or just something in srclib/ so it will
>>provide an independent library file (static, dynamic, or both)
>>so all users including httpd can link to that object. The
>>
>>apreq devs spent a considerable amount of time writing
>>the apreq module api so people could use apreq in any
>>C context- within an httpd module, a CGI script, or an
>>fcgi daemon. It'd be nice to preserve that flexibility
>>going forward.
>>
>>
>>Anyway I'm certainly willing to work on libapreq's build system
>>so it will not be dependent on apxs- it should be really easy
>>to do given that we just need apxs in a very limited way (basically
>>to get at the apr-*-config package scripts), I
>>just need to make the apache2 module build optional so just
>>the library gets built. That would entail pulling the apreq
>>source files out of server/ and just leaving the apreq2
>>filter module as part of httpd's build system.
>>
>>
>>
>>
+0
>
>I'm +1 for splitting and putting apreq2 filter in the build system;
it's what to do with libapreq2 that holds me back...
>
>I don't like the idea of "yet another library/dependency" for
building httpd, but after thinking about it, I probably wouldn't
want it as more clutter either in APR or in libhttpd either. I'd
likely change that to a +1 on the whole if I had even a whisper of a
rumor if anyone (other than the mod_perl folks) was planning on
incorporating apreq into some existing software to justify it being
a standalone library. I know we built for it, but I've yet to see
real adoption.
I'm not going to get into the whole question of who uses apreq outside
of mod_perl with you, because that's a boring waste of my time. The fact
that the ASF does should suffice. The point of the apreq module api is
to allow C authors to scale cleanly in either direction- it'd be a shame to abandon
a feature for C programmers that's already available to virtually every
dynamic programming language at this point.
Personally I'd just follow the mod_ldap module design for apreq and just
link the mod_apreq2 filter module to libapreq2. That avoids the whole bloatware
question about having it as a core dependency- users don't configure it in, it doesn't
effect the httpd build. Package managers could determine for themselves whether
or not to build apreq in by default.
What I'm really looking for btw is an easy migration path for existing mod_perl
users that provides the full featureset of libapreq2 in perl. Right now the
simplest thing I can think of is to leave mod_apreq2 in httpd's tree and move
the corresponding single-function XS for that module into mod_perl2 (once mod_perl
is ready to start supporting 2.4). Dropping the modules dir from libapreq's build
system is a one-line change- we'd of course keep the perl glue support for APR::Request.
|
