On Tue, Jan 12, 2016 at 12:13 PM, Rich Bowen <[email protected]> wrote:
> mod_fcgid is in a separate repo from the main httpd tree, due to > historical reasons. I presume there are good reasons for this. JimJag > suggested on IRC it's due to its independent release cycle. > > Be that as it may, because it uses the standard documentation tools for > the module docs, https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html > is full of broken links. In particular, try any of the directive and > links to other modules - try the mod_cgi or AddHandler links in the > intro paragraph, and you'll see immediately what the problem is. > > Now, we could of course have a separate version of the docs building > tools just for this module, or we could patch the doc manually, but I > was wondering, if there's no strong current reason for the module to be > kept separate, can we please move it into the main httpd tree? > 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). 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. Just my 2c USD, I'm open to ideas.
