| 1 | = Wiki Storage (#1132) |
| 2 | |
| 3 | This 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 | |
| 5 | Also, 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 | |
| 7 | For 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 | |