Feature Proposal:

Motivation

Several people have asked to be able to support different virtual hosts using the same core codebase. There is an existing solution, the VirtualHostingContrib, but it's a bit of a sledgehammer.

Requirements:

1. Multiple virtual hosts on the same server, running with mod_perl (for example)
2. All hosts share a common, standard install
3. Each host must have its own LocalSite.cfg
4. Each host must have its own set of extensions (not just plugins)
5. Hosts may share some webs (e.g. System)
6. Different hosts may run different versions of the same extension
7. Hosts will share base templates, but may use different skins and extension templates

This isn't so much a feature proposal as a research proposal. mod_perl supports some neat features (see http://perl.apache.org/docs/2.0/user/config/config.html#C_Clone_) for separating the service processes in virtual hosts. Since this gives you direct control over @INC, it should be possible to change the path to control:

1. Which (of several) LocalLib.cfg is picked up
2. Thus, which LocalSite.cfg is picked up
3. Which extensions (versions of extensions) are installed for each different virtual host

Currently one line in view controls where setlib.cfg is found:

    @INC = ( '.', grep { $_ ne '.' } @INC );

This forces setlib.cfg to be read from the same dir as the bin script. setlib.cfg uses FILE to locate LocalLib.cfg. LocalLib.cfg sets up $foswikiLibPath which gives control over where LocalSite.cfg is read from.

Let's say setlib.cfg were changed to get LocalLib.cfg from the @INC path if it can't be found in the FILE. That allows us to separate the code.

Outstanding question: how to separate/share data and pub? Should we assume the availability of soft-links on the server?

-- Contributors: CrawfordCurrie - 27 Sep 2010

Discussion

Note that there is an experimental NewApacheConfigGenerator that does things quite a bit differently - especially in setting handlers and supporting .htaccess files as well as the traditional apache configuration. (.htaccess files do not support Alias / ScriptAlias statements. so this version uses rewrite rules to set the handlers.) It's also been a bit more modularized by transcluding sections for the generated configuration.

-- GeorgeClark - 27 Sep 2010

Crawford, could you elaborate on VirtualHostingContrib being a sledgeghammer? I'd love to hear some feedback. (in special I don't quite understand the metafor of a sledgehammer in this context)

-- AntonioTerceiro - 28 Sep 2010

It's not a criticism; it's just that it monkey-patches the core, which is a fairly heavy thing to do (hence sledgehammer). It may be that it does enough to make that code directly useable in the core; though I don't think it quite addresses all the requirements (specifically separation of the @INC paths for each vhost)

-- CrawfordCurrie - 30 Sep 2010

Actually the monkey-patch approach was chosen because I needed to have it working with the current stable version (1.0.x), but in principle it could be moved to the core if there is enough interest, it's just a simple wrapper around Foswiki::UI::handleRequest.

But separating @INC paths will have a downside: you will need exclusive instances of Foswiki (with mod_perl, for example) to handle each virtual host. That could lead to a high memory footprint if you have a fair number of them. With VirtualHostingContrib, OTOH, backend processes can be shared between virtual hosts.

-- AntonioTerceiro - 01 Oct 2010

Sure; as with so many other things, it's a tradeoff. If you want to be able to offer users different @INCs, then there's a price to be paid on the server.

-- CrawfordCurrie - 01 Oct 2010