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