Feature Proposal: Ship FastCGIEngineContrib and ModPerlEngineContrib as core extensions

Motivation

It's a very common error to configure a site and try to use FastCGI or ModPerl without installing the optional Contribs. Including them in core would simplify new installs and avoid a recurring error on IRC. These are very small - ~90K each. And one or the other are very commonly used, and recommended for good performance.

Description and Documentation

Add FastCGIEngineContrib and ModPerlEngineContrib to the core extensions

Examples

Impact

Increase size of distribution put the EngineContribs under the release process, and simplify new installations.

I realize that we are in feature freeze, but this would be "low hanging fruit" I would think, very low risk. I'm adding myself as committed developer to start the clock and get notice.

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: GeorgeClark - 05 Aug 2010

Discussion

I would be good to get this into 1.1. We have been using FastCGIEngineContrib since Foswiki 1.0 and it has proved to be very stable, and the extensions we have installed work fine.

Of the open tasks for FastCGIEngineContrib, most of them have check-ins but I am not sure a new version has been released, so might need some testing.

-- AndrewJones - 05 Aug 2010

I have no issue with the proposal as such.

But 1.1 is out of the question. We are on feature freeze and we are more than 2 months delayed.

For 1.1 it is bug fixes only.

We have not even reached beta quality yet on 1.1.

The two contribs are both available for down load.

-- KennethLavrsen - 05 Aug 2010

I'm arriving late at this dicussion, but just to add my 2 cents: after I finished implementing FoswikiStandAlone and just before merging the implementation to trunk (it was at the other project days), I proposed EnginesAsContribs (it's yet Under Construction cause I didn't finish HTTPEngineContrib yet ). The motivation for that proposal was:

• Avoid adding dependencies to core
• Let the engines development independent of core development
  • No need to follow the core release proccess (I had many features to implement [and I still have them], but I didn't want to write proposals for each one of them)
  • Urgent bugs to any engine (except CGI) would not be release blockers
• Make the FSA acceptance process easier (at that time I feared people would not like the new dependencies and there is no need to have both FastCGIEngineContrib and ModPerlEngineContrib at the same time).
• FastCGI, ModPerl and other techniques to improve performance require more skilled administrators, so they would not face problems in installing an extension
• Other engines could appear over the time (and it doesn't make sense to add all of them to core)

Nowadays my main concern is about using core release process in those extensions, but I could live with that.

Note: I'd add my name to ConcernRaisedBy field, but the 14-day clock already expired.

-- GilmarSantosJr - 04 Sep 2010

Since this is now off the table for 1.1, and is under consideration for 1.2, I don't see that the clock needs to have expired. No reason to cut off discussion or decision making yet. I'll reset the clock. (It's really a packaging decision - I don't see that much development is required).

We've gone most of the 1.0.x cycle with them in use, and there have been very few urgent bugs so far. One urgent against Tasks.FastCGIEngineContrib, and none against Tasks.ModPerlEngineContrib. From questions on IRC they appear to be in fairly common use. So adding them to core would eliminate one of the major errors - forgetting to install them.

Nothing I suggested said that all engines would have to be added to core. I'm only proposing for these two. As far as new features go: If the core process is too onerous, is there any reason you couldn't create an EnhancedFastCGIEngineContrib or the like to add new features without running afoul of the release process, and then merge them back into core as they are proven?

It's really a kudos to your whole FSA / Engine concept that this has gone so smoothly with so few open tasks.

Anyway, clearing the clock for now so that discussion / objections can continue.

-- GeorgeClark - 04 Sep 2010

Let's not forget that 90% of new Foswiki users who download a Foswiki 1.2 or 2.0 that does have these bundled, still have no really good central document to read for setting up Foswiki "properly".

Such a document should include a comparison (matrix?) to help with decision making, because there are many options:

• mod_perl
• fastcgi (I wasted so many hours on this abandonware)
• mod_fcgid (I was using fastcgi as I had somehow mistakenly seen the fcgid project website with no updates since 2007; not realising it had been assimilated into apache.org itself)
• NativeSearchContrib search
• PurePerl search
• Forking search

And related:

• mod_headers/mod_expires/etags/ configuration
• .gz rewrite rules
• viewfile exceptions

So perhaps we should start a check-list which should be shipped in the System web, or something.

Anyway, I support the idea of making Gilmar's extensions core contribs, but not at the cost of holding back his plans. OTOH the current extensions are remarkably stable; and remember, we don't seem to require feature requests for refactoring, unless it affects user features in some way, so maybe development of those contribs could continue as normal anyway?

-- PaulHarvey - 05 Sep 2010

Paul mentioned the central point: the documentation is not good enough (and most FastCGI tasks are related to that). If we ship FastCGIEngineContrib and ModPerlEngineContrib as core extensions, then they should work out-of-the-box. In order to achieve that:

1. The extensions should be distributed with core (administrator doesn't need to install them separately)
   • Easy, just a packagins issue (as George pointed)
2. There should be the documentation Paul mencioned (and people should read...)
   • Not that easy. This document was never written, maybe it's very complex: if the administrator knows how to configure apache, the document would be small. Since it's not what happens in most cases, so the document would be very long and complex.
3. Administrators must install the dependencies properly (FCGI.pm and mod_perl-related stuff. IIRC RedHat doesn't have FCGI.pm package in the standard package set)
   • rpm-based distributions lack packages with FCGI.pm
   • If FastCGI is going to be used, ModPerl packages are not needed. If ModPerl is going to be used, FastCGI packages are not needed.
4. Administrators must configure webserver properly (ApacheConfigGenerator helps a lot, but it address only apache and doesn't handle hosting services)
   • The most common mistake is to not load the modules
5. Administrators should test if foswiki is setup properly
   • Both extensions lack documentation/mechanism to confirm they are working

Currently, if we just distribute both extensions with core, we save users from installing them, but more (complex) steps are still needed. OTOH, the development would become havier (probably the speed would be almost the same, since I haven't had much available time).

The main improvement I have in mind is to use FastCGI Authorizer Role and PerlAuthzHandler mod_perl handler to have permission checks on attachments (without the slow and havy viewfile). Others are documentation enhancements and mechanisms to check if the extension is in use.

Cause of the above analysis, I'd leave them as is today (non-core extensions), but I wouldn't bother if they become core extensions. I raised the concern to stop the clock (thanks George for resting it) and leave some time to discuss.

-- GilmarSantosJr - 06 Sep 2010

It's been a couple of years. I think it's time we address this. These contribs are very common and are required for a good performing Foswiki. I'm restarting the clock and unless new objections are raised, they will go into Foswiki 1.2 as default extensions. Gilmar, I'm removing you from the ConcernRaisedBy, since so much time has passed. Please re-raise it if you still have concerns.

Foswiki 1.2 configure has a much improved dependency checker. It will check core and all extensions as well. So this should help with the dependencies issues.

-- GeorgeClark - 01 May 2014