httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>
Subject RE: Was there any concrete decision on apreq?
Date Mon, 09 Mar 2015 09:43:37 GMT


> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]
> Sent: Sonntag, 8. März 2015 16:47
> To: dev@httpd.apache.org
> Cc: apreq-dev@httpd.apache.org
> Subject: Re: Was there any concrete decision on apreq?
> 
> On 08 Mar 2015, at 9:11 AM, Joseph Schaefer <joe_schaefer@yahoo.com>
> 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’t
> ideal - APR is a portability layer, and even though code is being accepted
> that “works with APR”, in reality we really need a libhttpd library that
> can provide “web server like stuff” in a proper true library form. Will
> certainly make tools in the “support” 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’t like that apreq as a loadable module, but I would love it as a
> proper shared library.
> 
> Same with the expressions code.

+1

Sounds sensible.

Regards

Rüdiger

Mime
View raw message