httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Bowen <>
Subject Re: mod_fcgid and broken doc links
Date Wed, 13 Jan 2016 21:50:14 GMT

On 01/13/2016 12:28 PM, William A Rowe Jr wrote:

> The reason for mod_ftp and mod_fcgid separate builds was historically
> that the same module, releasing on a different calendar than httpd, have
> been build-able independently against 2.0, 2.2 or 2.4.  Maintaining the 
> sources across the different branches was also something of a PITA.
> Maybe more significantly, mod_proxy_fcgi was our 'adopted' solution 
> to the fcgi case.  mod_fcgid is a different beast with process pool 
> management. I was always under the impression that for 2.4 and later, 
> we collectively wanted to express process pools independently of the
> mod_proxy_fcgi structure, much like we and tomcat would love to see
> folks use mod_proxy_http or _ajp rather than mod_jk.
> mod_ftp clearly isn't http:// so it never quite felt appropriate in that
> tree, but then again neither is mod_proxy_ajp :)  Which goes to the
> gist of it all, code bloat.  We've successfully only killed a tiny handful
> of modules in our entire history (imagemap, mem_cache etc). 

mod_imagemap still lives on in trunk. As does mod_cern_meta.

Point taken.

> So once merge to trunk, we own that code bloat for a very long time,
> but if it exists separate these can be enhanced or retired based on
> our desires.  E.g. if mod_aspdotnet had lived in modules/os/win32/
> we would still probably be shipping it, irrespective of how out of date
> that module becomes.
> I can see us moving those modules into trunk (not 2.4), retaining the
> mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release
> out of trunk/modules/fcgid/.  But I'm not clear why we would want to
> maintain the duplication between mod_proxy_fcgi and mod_fcgid?
> Individually they get little enough attention as it is.

Yes, it would be nice to merge them, from the perspective of explaining
things to users.

Rich Bowen - - @rbowen - @apachecon

View raw message