Description

• Executive Summary
• Rationale
• Proposal

Executive Summary

Have a method to allow pages to come from an alternative store

Rationale

There are a few difficulties that we run into when developing in xwiki:

• Collision issues when having multiple editors dealing with a single page (it seems that most people tend to copy the code from the browser, edit it locally, then paste it back when dealing with larger code changes -- sometimes forgetting to copy again in case someone else changes something, sometimes xwiki forgets that the page is being edited by someone else).
• Branching/deployment issues when moving from our development server to a staging server and finally to a production server (all files? how can one tell what files changed between them? etc.).
• Branching/deployment issues when working with "fixes" to a current issue to be deployed to a "current version" production server vs. new implementations to go to a "next version" of the production server (various branching issues here).
• Merging changes between different xwiki deployments (such as translation lookup page changes in production where the development page has been updated with new translation strings)

Proposal

There would be an alternate location (such as on the file system) where wiki pages would be stored.

• The initial proposal is to have a file system store, but this would probably be better to write as two plugins, one as the "alternative" selector and another as the file store (which could be replaced with other alternative storage locations)
  • Using a file system store, the directory could be maintained with any version control tool (eases issues with different branches where export/import has a number of issues)
• xwiki would pull pages from this directory instead of the database when a page exists there.

A number of issues would have to be solved, some very similar to issues with other proposals such as the WebDAV Service:

• File naming conventions
  • Current proposal (somewhat derived from WebDAV Service proposal) is:
    • Space/
      • Page/
        • wiki.txt (maybe something more like Space.Page.vm to make editing multiple pages easier when you don't see the directory name like in most editors)
        • attributes.xml (or could be split for some things title.txt, parent.txt, possibly in a subdirectory attributes/)
        • attachments/
          • attach1.png
        • objects/
          • object1.xml
        • class/
          • class.xml
        • lang_xx/ (for translated versions)
          • wiki.txt
          • attributes.xml
          • attachments/
            • attach1.png
          • objects/
            • object1.xml
• Priority of stores
  • If there is a page in both the alternative store and in the primary store, which takes priority?
    • One option here is to just have a configurable rule.
    • Another option is to have a thread doing one-way or bi-directional copying of the files if they are added/deleted/modified.
• Queries
  • Right now the use of $xwiki.searchDocuments() (at least in our usage) assumes that it is talking to a hibernate query backend, which may be difficult to make work with a file store.
    • Possibly the option of having pages copied to the primary store when they change on the alternative store resolves this as well.