All, Ludovic asked me to write this up on the wiki, but the page says that I should post it on the mailing list first (hopefully to get some initial feedback). 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) In discussing some of this with Ludovic, he was intrigued by the idea of using a file system directory to hold non-data wiki pages ("application" pages) and asked me to write up a proposal describing the idea. The general idea would be to have a method (plugin?) where application wiki pages could be maintained outside of the wiki database. There would be a directory where wiki pages would be stored. - This 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. I think this could be done as a plugin that wraps the default plugin. 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 on the file system and in the database, 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/updated. - 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 DB when they change on the filesystem resolves this as well. Feedback is more than welcome, David --