Edgewall Software

Changes between Version 1 and Version 2 of TracDev/Proposals/WikiNamespaces


Ignore:
Timestamp:
Jun 12, 2011, 1:25:36 PM (8 years ago)
Author:
Christian Boos
Comment:

Better state the goals that can be achieved by using namespaces

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/WikiNamespaces

    v1 v2  
    11= Adding Wiki Namespaces to Trac (#3021)
    22
    3 Namespaces will be useful mainly for two purposes:
    4  - flexibility of sharing/consolidating wikis between projects and subprojects (#130)
    5  - flexibility for using different storage backends (#1132)
     3Namespaces will be useful for the following reasons:
     4 - make it easy to share wikis between projects and subprojects (#130);
     5   initial consolidation of wikis coming from imported projects is facilitated,
     6   as the pages remain separate as long as needed
     7 - make it easy to choose between different storage backends (#1132)
     8 - have dedicated namespaces for special purpose pages, like `help:` pages (#3386), or `template:` pages (AdvancedWikiFormatting#Transclusion)
    69
    7 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.
    810
     11== Goals
     12
     13=== MultiProject support
     14The 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.
     15
     16For 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").
     17
     18=== Alternative storage backend
    919As 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.
    1020
     21=== Other features
    1122ticket:3021#comment:2 suggests the ability to reduce the scope of search to selected namespaces.
    1223
    1324There was some questioning in the comments about how Wiki Namespaces stand vs. the Wiki page hierarchy. See ticket:3021#comment:5 on that topic.
    1425
    15 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).
     26As 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).
    1627
    1728Note 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.
     
    2637For #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.
    2738
    28 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.
     39The "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.
    2940
    3041The "generic" backend is intended to be more flexible, notably with its ability to have any kind of custom properties (#695, #1386).