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
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
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