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 - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
