Re: Was there any concrete decision on apreq?

Graham Leggett <[email protected]> Sun, 8 Mar 2015 17:46:53 +0200
Newsgroups gmane.comp.apache.apreq,gmane.comp.apache.incubator.bigtop.devel
Message-ID <29730F54-75C9-4E19-B740-0085998D5075__16288.7586783201$1425829714$gmane$org@sharp.fm>
On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <[email protected]> =
wrote:

> In a nutshell the long term goal has always been to get the c parts of =
apreq incorporated into httpd distributions so the perl parts can ship =
with modperl.  This is still along those lines.  In order to continue to =
expose the cool cgi code that Issac added to libapreq we need to ensure =
there is an actual external library still when we ship with httpd =
otherwise we lose the modular features we spent so much time designing =
as apreq would then be limited to httpd modules only.  I'd like to see =
it serve the entire gamut of web apps including fast cgi.  That's what =
my ongoing plans are for the httpd project.

+1.

For ages library functions for httpd have ended up in APR, but this =
isn=E2=80=99t ideal - APR is a portability layer, and even though code =
is being accepted that =E2=80=9Cworks with APR=E2=80=9D, in reality we =
really need a libhttpd library that can provide =E2=80=9Cweb server like =
stuff=E2=80=9D in a proper true library form. Will certainly make tools =
in the =E2=80=9Csupport=E2=80=9D area of the httpd tree easier to =
develop for, as none of the tools have access to httpd proper, and code =
must be cut and pasted.

I don=E2=80=99t like that apreq as a loadable module, but I would love =
it as a proper shared library.

Same with the expressions code.

Regards,
Graham
=E2=80=94