[Moin-devel] A new feature for Wiki farms.

[Arlo Belshee]

Hi all.

I am running a Wiki farm, which I am currently upgrading from 1.1 to 1.2.1. In
the process, I thought of a feature that would be really convenient. Thus, I
am about to go implement it. However, before I did so, I thought that I'd send
a message to the list, with a few questions. Note: I am not on the list (as I
don't intend to be a regular MoinMoin developer), so please reply to me
personally, rather than on-list.

First, let me explain the feature that I'm thinking to add, then I'll list my
questions.

I have a number of wikis in my farm. These wikis have several things in
common, im particular all of the images, stylesheets, plugins, system pages,
some ACLs (eg, admin), and a number of other pages (like my tutorial for new,
non-technical, english-speaking users). It is fairly simple to make all wikis
on the site share most of these resources: anything which doesn't change and
can't be overriden by a specific wiki. This includes the code, images,
plugins, stylesheets, etc.

However, this does not include the pages.

So, what I propose to do is to modify the way that MoinMoin finds page files
on the disk. Basically, I'm adding a config var 'farm_data_dir', which
provides a second place to look for pages. The results of page search, read,
create, and write are the same as those for name resolution in Python.
Basically, the farm's data dir becomes the globals namespace, while that
wiki's data_dir is the locals namesapace. Thus:

1. Listing all pages finds the union of all names in the two sets (union of
keys in the dictionaries).

2. Reading a page's raw text off disk is a data access operation: it finds the
page in the wiki's data_dir first. If it doesn't exist, it reads it off the
farm's data_dir. The page is only "not found" if it doesn't exist in either
namespace.

3. There is no global statement, so all pages will be written to the locals
namespace. Thus:

  3a. Creating a new page that doesn't exist anywhere operates as normal - it
creates it in that wiki's data dir.

  3b. "Editing" a page that exists only in the farm actually creates a new
(occluding) page in the individual wiki's local data dir. The inital value
for that variable is accessed by a read operation, so is whatever was in the
farm's page. However, saving the new page is implemented as a page creation
for that one wiki, and so doesn't affect the wiki farm as a whole.

  3c. Editing a page that is part of the individual wiki is performed as normal.

4. The farm's global set is the regular data_dir for another wiki. This wiki
is the farm admin wiki. Changes implemented through this wiki operate as
normal for this wiki - writing to its local data_dir. This allows the admin to
change what is in the global pages, for all wikis.

5. The farm admin may choose, if he desires, to make certain pages (eg, system
pages) be non-writable / non-creatable by anyone other than himself. This will
prevent them from being overwritten by pages in any of the wikis in the farm
(eg, protect the integrity of the Help pages). This is, of course, purely
optional on the admin's part.

So, now for the questions.

First, what do you think about this feature? Are you interested in having it
added to the offical MoinMoin codebase?

Second, many of you have better knowledge than I of the MoinMoin codebase.
I've looked through it, and this change looks to be rather invasive - with a
number of potentially bizarre side effects. Do any of you know of an elegant
way to make the change? It looks to me to require changes to Page, PageEditor,
and several functions in wikiutil (getPageList, getPageDict, getBackupList,
getSysPage, getHomePage, and getPagePath. Potentially also isSysPage, etc). Is
there actually a fracture point already in the code for this sort of change,
which I'm just not seeing?

Do any of you have any other suggestions as I set about this? Is there
anything in general that I should keep in mind (I've tinkered with the
MoinMoin code before, but am not a developer of it)?

Thanks for your help as I work on this.

Arlo