This document details a planned roadmap for the extension manager module. The goals are split into two groups. The main group are "Planned Goals" which are fairly well understood and on the plan for implementation. The "Research Goals" are items that may be included in the plan at a later time but as yet either need more definition or evidence of need.

The following points should be noted when reading this plan:

• It only lists the "big ticket" items. Other fixes will be ongoing in parallel to these.
• As big items, while their completion may fall before a given Firefox release, they still may be deferred to ship in later releases (e.g. none of them are shipping in Firefox 3.1).
• The timescales and plans are all subject to change, hopefully this page will be kept updated as changes are made.

High Level Roadmap

This is the overall plan for what order and when the goals will be implemented. Some goals have dependencies which enforce the order of execution, others are ordered based on a good fit between priorities, dependencies and providing regular visible improvements for all parties. This should ensure that there are new exciting features for a potential 1.9.2 release if there were to be one.

The timescales are only rough guesses at this point based on two people doing the bulk of the implementation and reviews.

Target Audiences

Changes to the extension manager have varying target audiences. Most goals should be relevant to at least one of the following audiences:

• Application users
• Application developers
• Add-on developers

Goals that are not relevant to any of these or are not requirements for other goals should be questioned. This is not an absolute requirement of course, some goals are worthy purely because they simplify code yet have no visible effects.

Planned Goals

EM-001 API Improvements

References: Draft Specification, bug 461973

Target Audience: None

Requires: Nothing

The current extension manager API is very sparse. It mostly allows you to affect changes to the add-ons list but not query very much information without delving into the raw RDF. In order to allow the UI and other tasks to stop using the RDF datasource we must implement a more comprehensive API.

EM-002 SQLite Backend

References: Draft Specification, bug 449585

Target Audience: None

Requires: EM-001

The current code uses an RDF backend for caching extension metadata and state. The platform is moving away from RDF in many places and sqlite offers better fault tolerance.

EM-003 User Interface Reorganisation

References: Draft Specification, bug 397581

Target Audience: Application users, Application developers

Requires: EM-001

The current UI splits the different add-on types. But it is unclear to most users what the difference between then really is. The change suggested is to mostly unify the list however also splitting the actions out from the list and into an inspector panel makes it easier for applications to provide their own functionality and it would be more natural to allow actions for multiple items.

EM-004 Install/Uninstall Hooks

References: Draft Specification bug 416246

Target Audience: Add-on developers

Requires: Nothing

Add-on developers frequently need to perform initial setup and cleanup operations when their add-ons are installed and uninstalled. This feature would allow this in all circumstances where currently it is impossible for the add-on to detect a change in state.

EM-005 Install Without Restart

References: bug 256509

Target Audience: Application users

Requires: EM-004

For the majority of add-ons it should be possible to cause the add-on to start working immediately without the need for restarting the application.

EM-006 Replace RDF Formats

References: Draft Specification, bug 461975

Target Audience: Add-on developers

Requires: Nothing

RDF is painful to read and write. While it is not great that authors could have to learn something new, so long as we continued to support the rdf forms switching to something new would make new author's lives easier. Either a simple xml schema or json are likely candidates.

EM-007 Application Specific Metadata

References: bug 461976

Target Audience: Application developers

Requires: EM-002

Applications may have needs to hold additional information about installed add-ons. This may either be set based on the add-ons install manifest or even changed during use to hold data specific to the add-on and application.

EM-008 Add-on Dependency Resolution

References: Outdated specification bug 345610

Target Audience: Add-on developers

Requires: Nothing

The current dependency system is basic and offers users no way to find and install the required add-ons. This feature would allow looking up dependencies and offering to install them automatically.

Research Goals

Add-on Categorisation

Potentially as part of the UI reorg or just generally it can be useful to applications to be able to put add-ons into categories. This is sort of like metadata but some special handling would be required to allow getting lists of add-ons based on the category etc.

Remove EM Restart

Currently if the list of add-ons changes on the next startup we must go through a process of (un)registering add-ons and then have the application completely restart. It may be possible to remove this requirement and just continue with the general startup leading to a much faster restart after changing add-ons.

Add Add-on Conflict List

Some add-ons are simply incompatible with others. Sometimes this is due to poor coding behaviours but often they simply do similar jobs and so cannot co-exist. We may consider having the extension manager download a list of known conflicts from a trusted source, maybe as a part of the blocklist service, that then warns users as they try to use two add-ons known to conflict with each other.

XPInstall Replacement

XPInstall is currently little more than a downloader for the extension manager. A lot of the download and install process would be simplified by simply handling the download within the module or by using something more advanced like the download manager.

Add-on Locale Packs

It is currently possible for localizers to ship simple locale pack xpi's for extensions however the UI is not really set up for it and so it would likely come across more confusing than useful. We could improve the UI to properly tie locale packs to their target.