Edgewall Software

Changes between Initial Version and Version 1 of TracDev/Proposals/WikiStorage


Ignore:
Timestamp:
Jan 6, 2011, 11:59:17 PM (9 years ago)
Author:
Christian Boos
Comment:

making the storage backend of wiki pages pluggable

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/WikiStorage

    v1 v1  
     1= Wiki Storage (#1132)
     2
     3This proposal is about implementing new storage backends for wiki pages. This started mainly as an effort to implement the #1132 ticket, but has some more far reaching consequences, notably that I chose this as the starting point for experimenting with [GenericTrac#AppliedonWikimodule GenericTrac].
     4
     5Also, when thinking about the proper way to make the storage backend configurable, I realized this had not to be an all or nothing choice, provided we coupled that with the WikiNamespaces idea developed in #3021. A given namespace has one storage backend, and multiple namespaces can happily coexist, for different purpose and breadth of use. See related proposal for details.
     6
     7For historical background, see TighterSubversionIntegration and [[WhySQLite]]. The arguments presented there tend to defend one approach versus the other, whereas here we show that with some flexibility we can propose a palette of solutions that can cover all the needs (including the //status quo// ;-) ).
     8
     9== Implementation plan
     10
     11 - extract the code related to specificities of the current database model in a !TraditionalWikiStorage component
     12 - associate a storage backend to the default wiki namespace `wiki:` via a configuration setting:
     13   {{{
     14   [wiki]
     15   default_storage_backend = TraditionalWikiStorage
     16   }}}
     17 - introduce a `RepositoryWikiStorage` component that delegates the storage operations to a VCS in a dedicated repository (the repository has to be created first)
     18   {{{
     19   [wiki]
     20   default_storage_backend = RepositoryWikiStorage
     21   default_wiki_repository = wiki
     22   }}}
     23   - this leaves open the question whether attachments should be stored there as well;
     24     maybe do that in a second step?
     25   - what about indexing? Do we want to special case a wiki repository or do we want to take this opportunity to implement #3541? Start with //no// search capabilities.
     26   - storage details: would be nice to have pages stored with `.wiki` extension (and map that to x-trac-wiki, btw), as this will make life easier for people editing pages with an editor from a checkout. In addition, this will solve the problem for subwiki pages:
     27     - TracDev -> `/TracDev.wiki`
     28     - TracDev/Proposals/WikiStorage -> `/TracDev/Proposals/WikiStorage.wiki`
     29   This will also make it possible to store attachments easily:
     30     - TracDev -> `/TracDev.wiki`
     31     - attachment:image.png:wiki:TracDev -> `/TracDev.attachment/image.png`
     32   If extra attributes have to be stored, they could be placed in a `TracDev.<field>` file.
     33   We should also add some extra limitations to the allowed page names, so that a checkout can work on Windows (i.e. no characters in `"\\/:*?\"<>|"`)
     34 - introduce a `GenericWikiStorage` component that implements an improved in-db storage scheme (GenericTrac#Base). This would allow to implement advanced features, like #695 and #1386.
     35 - introduce WikiNamespaces (+ add that page to the TracGuide)
     36   - objectify WikiNamespaces (GenericTrac#Base), have a `namespace:` resolver
     37   - add a dispatching mechanism from a namespace to a backend, similar to the one used for repositories, possibly abstracting some code? Although this should be simpler as we could require naming the storage backend explicitly (as the `backend` property of the namespace. If it's `RepositoryWikiStorage`, then the extra `repository` property is also needed to indicate //which// repository contains the wiki).
     38 - introduce a mixed db/repository storage, `RepositoryDbWikiStorage`, which combines the advantages of both the `RepositoryWikiStorage` system and the `GenericWikiStorage` (for queries and search); this is the "ultimate" combination touted in GenericTrac#History
     39 - implement AdvancedWikiOperations for the backend that support it (`RepositoryWikiStorage` and `RepositoryDbWikiStorage`)
     40