= Project classifiers (aka labels) = #Introduction Consider merging this page with [wiki:TracDev/Proposals/MultipleProject Multi-Project Support for Trac] In order to provide an structured solution so as not to limit the possible ways of grouping projects it is convenient to introduce the concept of '''project labels'''. Main goals are the following : - Offer a structured mechanism to identify a group of projects no matter what hierarchy is involved . - Encapsulate these details at the API level while determining (multi)project context. Considering the [wiki:TracDev/Proposals/MultipleProject#ProjectTree reference example], in spite of searching for tickets in `Family A` and `Family B` but not in `Tools` and `3rdParty` when needed, a label containing both projects has to be created (either ''explicitly'' or ''implicitly'', see [#SpecialLabels below]) . This document also suggests alternatives and approaches to implement some features defined in [wiki:TracDev/Proposals/MultipleProject Multi-Project Support for Trac]. Some content may actually overlap aforementioned specification. == URL space for different projects == #UrlMapping A constraint should be imposed in order to simplify dispatching strategy so as to map projects to ''URL''s. Project short name '''MUST''' be unique in the context of an environment. - '''host mapping''': the name of the (virtual) host used to access the ''Trac'' environment is taken to be the name of the project. A given host can be configured to be an alias for the default, top-level project. Label names are not allowed to be used this way. - '''prefix mapping''': if the `PATH_INFO` starts with `/p//` prefix, name of a project will be taken to be `` . Otherwise if it starts with `/l//` then the request is addressed to the set of projects included in label ``. In general this is less ambiguous than the [wiki:TracDev/Proposals/MultipleProject#URLspacefordifferentprojects mapping suggested in original proposal]. Explanation and implementation details provided [#UrlExplained below]. == The Data Model and the API == #DataModelApi Labels may be considered as resources bound to the environment rather than to particular projects (e.g. like `Changeset` and `Source` which belong to a given repository - see MultiRepos). Hence only an additional `labels` table is also needed, and it can take the form of a ''resource table specialization'' from the GenericTrac. Project labels should have at least short name (and maybe description) field. Project labels can be linked explicitly to projects and labels (if using [#NestedLabels nested labels]). These connections can take the form of ''relations'' from [wiki:TracDev/Proposals/TracRelations Trac Relations]. === URL prefix mapping explained === #UrlExplained Project-specific URLs will start with `/p/` prefix. Requests involving multiple projects will be made available on a per-label basis at ''URL''s starting with `/l/