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:
- Multiple virtual hosts on the same server, running with mod_perl (for example)
- All hosts share a common, standard install
- Each host must have its own LocalSite.cfg
- Each host must have its own set of extensions (not just plugins)
- Hosts may share some webs (e.g. System)
- Different hosts may run different versions of the same extension
- 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:
- Which (of several) LocalLib.cfg is picked up
- Thus, which LocalSite.cfg is picked up
- 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