Adding Wiki Namespaces to Trac (#3021)
Namespaces will be useful for the following reasons:
- make it easy to share wikis between projects and subprojects (#130); initial consolidation of wikis coming from imported projects is facilitated, as the pages remain separate as long as needed
- make it easy to choose between different storage backends (#1132)
- have dedicated namespaces for special purpose pages, like
help:pages (#3386), ortemplate:pages (AdvancedWikiFormatting#Transclusion)
Goals
MultiProject support
The main idea is to decouple wikis from projects to allow for maximal flexibility, in much the same way this will be done for repositories. That way, some wikis can be shared between some projects or on the opposite made private to them.
For example, the main wiki: namespace, as well as the help: namespace (for Trac documentation pages), could be shared by all projects. At the other extreme, each project could have its own private namespace by using the same name as the project name. This fits with the use of the project name as an InterTrac prefix. For example, in the context of "ProjA", the WikiStart page will be the ProjA:WikiStart page if there's one, the global wiki:WikiStart page otherwise (but maybe we'll need an more specific way to specify the toplevel wiki namespace, like :wiki:WikiStart?). Some projects could benefit from using more than one namespace, for hosting separated sets of pages ("WikiDocuments").
Alternative storage backend
As for the flexibility concerning the backends, one could decide to save the important pages in a version control system, but to have for example "Talk:" pages saved in the db only. Or for easier migration, convert an existing namespace from the "traditional" backend to a new namespace with another backend, then at a later time rename the old namespace to "old" and rename the new one to the original name.
Other features
ticket:3021#comment:2 suggests the ability to reduce the scope of search to selected namespaces.
There was some questioning in the comments about how Wiki Namespaces stand vs. the Wiki page hierarchy. See ticket:3021#comment:5 on that topic.
As we've already seen above, there's a close relation between Wiki namespaces and link resolvers. Syntactically, a namespace is a kind of link resolver, like an InterTrac or InterWiki prefix, like Project names will be, and like any other link resolver currently is. This similarity leads to an interesting migration path which can lead from a "generic" wiki to dedicated subsystems. Imagine an User: namespace like in MediaWiki, initially based on simple wiki pages, but later evolving into a dedicated subsystem as hinted in #4588. Same thing for a "component:" namespace populated with wiki pages describing ticket components. From a simple namespace of normal wiki pages, this can later evolve into a dedicated subsystem similar to what we have now for Milestones (#5211).
Note also the relation with the NewHelp proposal, as it could also benefit from a Help: namespace associated to a local db backend for the help wiki pages, or simply be redirected to a remote Trac if Help is instead registered as an InterTrac prefix; later this link resolver could be targeted to a new subsystem, the one described in the NewHelp proposal.
About namespaces in other wikis, see also:
Implementation details
For #1132, we started to make the storage backend pluggable. One such backend can simply delegate the storage to a dedicated repository. The others are the "traditional" and "generic" database storage models.
The "traditional" backend can only be used for the default main namespace, as there's currently no provision for storing the namespace name. There's also no need to add it, as keeping that backend is for transition only, or for keeping a status quo for people who don't need any of the new features and are satisfied with the existing.
The "generic" backend is intended to be more flexible, notably with its ability to have any kind of custom properties (#695, #1386).
