Adding Wiki Namespaces to Trac (#3021)

Namespaces will be useful mainly for two purposes:

• flexibility of sharing/consolidating wikis between projects and subprojects (#130)
• flexibility for using different storage backends (#1132)

For example, the main wiki: namespace, as well as the help: namespace (for Trac documentation pages), could be shared by all projects, but in addition to this, some projects could have their own private namespace (same name as the project). Conversely, some projects could have more than one namespace, for hosting separated sets of pages.

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.

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.

There's an even closer 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:

• ​DokuWiki Namespaces
• ​MediaWiki Namespaces

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 back 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).