Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=wQ/WXBoF0YEBC5jiokofp0SmKHEEiJBZOzbW9MW6twfEZ/sUyvgjYWd1ewLa6CJEjoj9iDDXv3W7LoivamrNdjEPaQSdAgjl7cnhPSGRoyTNcp9u2xaye74D1DCUrykBWFqu3a94WBmBodvV+gKUr/8F0KfUVsc7QS61vTk7OfQ=;
References: <1335492759.77968.YahooMailNeo@web160901.mail.bf1.yahoo.com>
 <4F9A34CA.2000902@beamartyr.net>
Message-ID: <1335507524.61281.YahooMailNeo@web160906.mail.bf1.yahoo.com>
Date: Thu, 26 Apr 2012 23:18:44 -0700 (PDT)
From: Joe Schaefer <joe_schaefer@yahoo.com>
Reply-To: Joe Schaefer <joe_schaefer@yahoo.com>
Subject: Re: packaging libapreq2 as a dependency
To: "dev@httpd.apache.org" <dev@httpd.apache.org>
In-Reply-To: <4F9A34CA.2000902@beamartyr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

>________________________________=0A> From: Issac Goldstand <margol@beamart=
yr.net>=0A>To: dev@httpd.apache.org =0A>Sent: Friday, April 27, 2012 1:55 A=
M=0A>Subject: Re: packaging libapreq2 as a dependency=0A> =0A>=0A>On 27/04/=
2012 05:12, Joe Schaefer wrote: =0A>Now that some time has passed since Phi=
lip brought=0A>>apreq2 into trunk it's probably a good time to discuss=0A>>=
how best to incorporate it into httpd itself.=A0 Right=0A>>now the library =
files are in server/ which basically=0A>>means we're internally compiling l=
ibapreq2 into httpd.=0A>>=0A>>=0A>>Personally I'd prefer to see libapreq2 b=
undled as an=0A>>upstream dependency, ie put the library into an associated=
=0A>>deps package or just something in srclib/ so it will=0A>>provide an in=
dependent library file (static, dynamic, or both)=0A>>so all users includin=
g httpd can link to that object. The=0A>>=0A>>apreq devs spent a considerab=
le amount of time writing=0A>>the apreq module api so people could use apre=
q in any=0A>>C context- within an httpd module, a CGI script, or an=0A>>fcg=
i daemon.=A0 It'd be nice to preserve that flexibility=0A>>going forward.=
=0A>>=0A>>=0A>>Anyway I'm certainly willing to work on libapreq's build sys=
tem=0A>>so it will not be dependent on apxs- it should be really easy=0A>>t=
o do given that we just need apxs in a very limited way (basically=0A>>to g=
et at the apr-*-config package scripts), I=0A>>just need to make the apache=
2 module build optional so just=0A>>the library gets built.=A0 That would e=
ntail pulling the apreq=0A>>source files out of server/ and just leaving th=
e apreq2=0A>>filter module as part of httpd's build system.=0A>>=0A>>=0A>>=
=0A>>=0A+0=0A>=0A>I'm +1 for splitting and putting apreq2 filter in the bui=
ld system;=0A=A0=A0=A0=A0it's what to do with libapreq2 that holds me back.=
..=0A>=0A>I don't like the idea of "yet another library/dependency" for=0A=
=A0=A0=A0=A0building httpd, but after thinking about it, I probably wouldn'=
t=0A=A0=A0=A0=A0want it as more clutter either in APR or in libhttpd either=
.=A0 I'd=0A=A0=A0=A0=A0likely change that to a +1 on the whole if I had eve=
n a whisper of a=0A=A0=A0=A0=A0rumor if anyone (other than the mod_perl fol=
ks) was planning on=0A=A0=A0=A0=A0incorporating apreq into some existing so=
ftware to justify it being=0A=A0=A0=A0=A0a standalone library.=A0 I know we=
 built for it, but I've yet to see=0A=A0=A0=A0=A0real adoption.=0A=0A=0AI'm=
 not going to get into the whole question of who uses apreq outside=0Aof mo=
d_perl with you, because that's a boring waste of my time.=A0 The fact=0Ath=
at the ASF does should suffice.=A0 The point of the apreq module api is=0At=
o allow C authors to scale cleanly in either direction- it'd be a shame to =
abandon=0Aa feature for C programmers that's already available to virtually=
 every=0Adynamic programming language at this point.=0A=0A=0APersonally I'd=
 just follow the mod_ldap module design for apreq and just=0Alink the mod_a=
preq2 filter module to libapreq2.=A0 That avoids the whole bloatware=0Aques=
tion about having it as a core dependency- users don't configure it in, it =
doesn't=0Aeffect the httpd build.=A0 Package managers could determine for t=
hemselves whether=0Aor not to build apreq in by default.=0A=0A=0AWhat I'm r=
eally looking for btw is an easy migration path for existing mod_perl=0Ause=
rs that provides the full featureset of libapreq2 in perl.=A0 Right now the=
=0Asimplest thing I can think of is to leave mod_apreq2 in httpd's tree and=
 move=0Athe corresponding single-function XS for that module into mod_perl2=
 (once mod_perl=0Ais ready to start supporting 2.4).=A0 Dropping the module=
s dir from libapreq's build=0Asystem is a one-line change- we'd of course k=
eep the perl glue support for APR::Request.