Extension Manager:Future Work
These are ideas for the future. Priorities are P1-4, 1 being highest. Size is an estimate of the amount of work required, S/M/L.
| Description | Priority | Size | Owner | Schedule |
| Sqlite storage
The current code uses an rdf backend for caching extenstion metadata and state. This should be converted to sqlite. | P1 | L | ||
| Install add-ons without restart
We will probably have to restrict this some. So only installs, not upgrades and add-ons will have to be specially written to take advantage of it, expecting special signals to say they have been loaded after the normal startup. | P1 | M | ||
| UI reorganisation
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. | P2 | L | ||
| Drop XPInstall
XPInstall is currently used for downloading and certificate verification of xpi's. This functionality could be moved to the extension manager to remove complexity. | P2 | S | ||
| Unified error logging
Extension authors have to look all over the place for errors relating to installation, component registration, overlays and templating. These could all be brought together into one place. | P2 | S | ||
| Blocklist plugins by file version
We currently rely on plugin vendors including the plugin version in one of the name, filename or description of the plugin. On windows the dll also contains a version number that many vendors use, we should start reading this and make the blocklist able to match on it. | P2 | S | ||
| Locale packs for add-ons
This would allow localisers to release a locale pack separately to the main add-on. This can help make localising add-ons an easier process since the main author has to do nothing but make sure the add-on is localisable. | P3 | M | ||
| Split out the startup code
We can defer loading of the main component until it is really needed which for the majority of startups is never. | P3 | M | ||
| Addon Conflict Resolution
When a dependency on another add-on exists we should be able to offer and download and install the dependencies automatically (presumably using AMO as a lookup for the dependencies) | P3 | M | ||
| Sandboxing extension code
It would be nice to be able to sandbox certain extensions so they don't have certain privileges like writing to the local disk. | P3 | ? | ||
| Multiple compatibility ranges per application
It is currently impossible to distribute a single add-on that is compatible with two different min/max version ranges of one application. | P4 | S | ||
| Improve blocklist interaction with plugin host
The blocklist has to rescan and check every plugin whenever a new plugin is detected at the moment. Instead the plugin host should just ask the blocklist if the new plugin is blocked or not in the same way the extension manager does | P4 | S | ||
| Better install/uninstall hooks
Fairly common request from add-on authors is to do things on install/uninstall. There are some existing hooks to handle this but they could be made easier to use. | P4 | S | ||
| Replace install/update.rdf
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. | P4 | S |