Description

Feature Story

I see a few needs for this. The first is that users would like to augment the shipped documentation for the Moin wiki and have it automatically shared/available in the Farm subwikis. For examples, you might write a page documenting a particular extension or convention on your wikis. Right now the mechanism would be to create the page and as a system admin, move the page into the underlay directory (something that can't be done from the web interface). If you move it to the underlay, you risk losing it on Moin upgrades.

I'm using wiki in a corporate environment, we use a wiki farm for each major project/program that we develop and we have a general InfoWiki which contains user home pages and general information not related to a specific project. This means that we have lots of common pages that it would easier to share simply (as a wiki word), then require all users to remember to type CommonWiki:PageName. This is very necessary in terms of having common user home pages. When somebody types KeithSchwols on any page in any subwiki, it would nice if they got the common, overlay version of page automatically. (Right now, each user is required to create a home page on each subwiki and #redirect it to their common overlay area).

Implementation Discussion

Conceptually, this would function like the underlay pages. When the moin engine attempts to locate a page, first look in the local wiki. If it is not found, the code currently looks in the underlay directory - it could look in an 'overlay' area first.

If moin finds the page in the overlay, it can just bring it up for normal operation (view/edit/etc), if it doesn't find the overlay it can continue with the underlay search and operation. I think another difference in the operation should be that you can edit the 'overlay' page in place - the current underlay code copies the underlay to the local wiki when edited.

The FarmConfig class already has a data_dir and data_underlay_dir defined, in that pattern, we should have data_overlay_dir (or perhaps data_shared_dir)

I think that instead of another single cfg var it should be a search path option that is the ordered list of data dirs to locate pages in, the data_dir and data_underlay_dir cfg values can be used to identify if the page is in the main area for the wiki or the underlay as the current implementation does the other entrys would be the overlays. editing a page that is an underlay would copy it from the underlay location to the data_dir location. for example the config without using an overlay would be 

    data_dir = './data/'
    data_underlay_dir = './underlay/'
    page_data_dirs = ( './data/', './underlay/' )

and the config for using an overlay would be 

    data_dir = './data/'
    data_underlay_dir = './underlay/'
    page_data_dirs = ( './data/', './overlay_data/', './underlay/' )

Current Workarounds

I should also note that I currently work around some of this by using symlinks. I found that I can symlink the page in a subwiki to the commonwiki and get the behavior I desire. The page appears to be native to both wikis and when users edit the page; to them it appears as both subwikis got the update. However, this is an extra step to manually symlink new pages on the common wiki to all the projectwikis and doesn't allow if we really want to break the link and have pages with the same name but different content. This is better than creating a bunch of stub pages with #redirects because the search engine finds the content on the pages too.

Progress/Discussion

I'm currently working on this for my corporate wiki farm as I get parts working I will try publish it on a public wiki farm for others to comment on. Right now I'd like to hear what people think of this FeatureRequest and ideas to improve on what I laid out above.

I had a short look at the patch: it's impressive what you did in your patch. :) Especially because that part of the moin code is rather confusing sometimes.

IIRC, we had that "layered storage idea" already discussed on some other page, but we didn't implement it yet because I rather liked to have a clean storage api first. Using that storage api, we could just have "page providers" caring for 1 layer of pages in some storage type (e.g. in a fs directory). And then have some storage-independant high-level code doing the layering stuff with an arbitrary list of 2,3,4,more such storage providers.

As you might have seen, we tried to do that storage api in summer of code 2006, but it wasn't completed. As a consequence of that, I did some simplifications of storage code in 1.6 branch (removed the unused hierarchical storage support). Because of performance issues in 1.5, there is also a new caching system in 1.6. Due to these changes, I think your patch won't apply to 1.6 branch.

-- ThomasWaldmann 2006-11-28 07:30:55

Patch 1.5.6

I now have a working patch against 1.5.6 not yet available on a public wiki farm.

overlay-1.5.6.diff

Here is a fix to the patch above for wikis that are a single Wiki, (DefaultConfig vs FarmConfig) 

Index: multiconfig.py
===================================================================
--- multiconfig.py      (revision 245)
+++ multiconfig.py      (working copy)
@@ -616,10 +616,11 @@
         """
         if not hasattr(self, 'page_data_dirs'):
            data_dir = getattr(self, 'data_dir')
-           underlay_dir = getattr(self, 'underlay_dir')
            self.page_data_dirs = [ data_dir, ]
-           if underlay_dir:
-               self.page_data_dirs = [ data_dir, underlay_dir, ]
+           if hasattr(self, 'data_underlay_dir'):
+               underlay_dir = getattr(self, 'data_underlay_dir')
+               if underlay_dir:
+                   self.page_data_dirs = [ data_dir, underlay_dir, ]

         mode = os.F_OK | os.R_OK | os.W_OK | os.X_OK
         for attr in ('data_dir', 'data_underlay_dir', 'page_data_dirs'):

Patch 1.6-7b80735ede14

Here is a patch against 1.6 7b80735ede14.

overlay-1.6-7b80735ede14.diff

CategoryFeatureRequest

MoinMoin: FeatureRequests/OverlayPagesForFarms (last edited 2007-10-29 19:06:40 by localhost)