NOTICE: This is a work in progress. Please file your suggestions and comments under ticket #10217.

NOTICE: Development on this has already begun and will be made available on ​https://github.com/axnsoftware/trac-bugs-n-features/tree/trac-issue-10217 as soon as I have internet access over at my company's place, duh, damn providers…

The Context

Having multiple Trac instances or projects leaves you basically with two options.

1. You set up multiple instances of either the Trac standalone server, binding it to either different IP addresses or ports, or configure apache so that you will have multiple virtual hosts prepared for servicing the multiple independent projects, most provably also using different ports for each project. Of course you will also have to configure your resolver, be it either a DNS or your local /etc/hosts db;

2. You use the Trac standalone server or a suitable apache virtual host configuration, and Trac's env-parent-dir option to provide a rudimentary index of your projects from which you then can dive into your existing projects;

The Problems

• While option 1 is definitely more flexible, it leaves you with a lot of host names a/o ports to remember on how to access your projects in the first place;

• While option 2 is more simpler, it already provides you with an aggregated list of your existing projects, from where on you can simply navigate to individual projects that you are currently working on;

• The biggest draw back of option 2 is that it leaves you with only a simple project index that by no means provides you any more options nor the power managing your existing projects from an aggregated point of view;

• And by no means, one will ever be able to search across all projects, nor will one be able to aggregate information from all projects into a single page, for example a dash board, unless you implemented such a feature by yourself, using even more external tools and customizations to get the job done;

The Goals

• The portal should be omnipresent in that existing projects and their modules blend into the portal's layout and design, but still allow individual projects to provide a custom logo and icon for their site;

• Replace the current env-parent-dir option with an optional portal environment that will allow users to write new components for the portal and also portlets in order to enhance your experience of an aggregated view on your existing projects. And, if no portal environment exists, the standard behaviour will be used as a fall back;

• Other use cases, for example browser based registration / creation of new projects, or the termination of existing projects, single-sign-on, hierarchical project layouts, individual project level sub domains, and even more could be achieved by using the portal approach and proper integration of the existing solutions such as apache etc.;

Proposed Solution

• A new trac-portal-admin console will be introduced for setting up / administering a portal instance;

• A Trac Portal instance will have its own database, its own configuration and templates and so on;

At the source level, the following innovations will take place

• A new trac.portal package will be introduced;

• trac.web.main will be adjusted so that it will detect a portal instance or use the default env-parent-dir behaviour if no such environment exists;

• Portal specific extension points (IPortal…) will be introduced, which have to be extended upon by PortalComponent derived components. All portal components must be registered with the trac.portal.component entry point;

• A new trac.portal.api Portlet API and Portal Component API will be introduced, with IPortlet being the sole portlet extension point in the system. Portlets will also be standard Trac Components, and they must be registered with the trac.portal.portlet entry point;

• Portlets serve as content providers, they themselves are using so called content aggregators, which in turn make use of so called content sources. Portlets can support rendering content in multiple different formats, based on so called content types. The least common denominator is considered text/plain, however, in a web based environment we consider it to be text/html. A portlet that supports rendering of its content in for example text/html and text/rdf+xml or even text/atom+xml, will adopt to content-type specific user requests, provided that the portal allows one to retrieve a feed from a single portlet at a time…

• A new <portlet…/> Genshi directive will be introduced for authoring the portal template;

• Portal Components behave just like standard Trac Components in that they extend upon the existing features or provide new extension points to the system.

• TBD

Initial Set of Portlets

• SearchPortlet — allows one to search across all projects under the reign of the portal
  • LocalSearchAggregator — aggregates search across all locally accessible projects, available search sources are provided by the project's ISearchSourceS

• TimelinePortlet — allows one to diplay an aggregated time line of events across all projects and even the portal itself
  • LocalTimelineAggregator — aggregates time line events across all locally accessible projects, including the portal, available sources are the time line event sources that are provided by the project's ITimeLineProviderS and the portal

• ProjectIndexPortlet — provides a navigable project index
  • LocalProjectIndexAggregator — aggregates the locally accessible projects
    • LocalProjectIndexSource — a project index source

• TicketPortlet — allows one to display an aggregated ticket list across all projects (except for the portal which does not have a ticket system);
  • LocalTicketAggregator — aggregates tickets from the locally accessible projects

• TBD

Initial Set of Portal Modules

• trac.portal.prefs — replaces the preferences for all of the projects reigned by the portal;
• trac.portal.search — provides a search results page and the search portlet(s);
• trac.portal.admin — provides the trac-portal-admin console and the portal's admin web interface;
• trac.portal.project — provides a wrapper for existing projects under the reign of the portal;
• trac.portal.timeline — provides a navigable time line summary page and the time line portlet(s);
• trac.portal.portal — the portal itself
• TBD

Discussion of Design Decisions Made

• The new entry points trac.portal.component and trac.portal.portlet will keep the standard environments from loading portal level components and they will also help keep the portal from loading standard environment components during initialization of the environment;

• By having two distinguished entry points, the portal is able to separate concerns between portlets, i.e. components that will be evaluated at the template level, and actual portal extensions, for example modules that would provide for portal level preferences and so on.