canmove, Confirmed users
1,570
edits
(New page: * Addon Conflict Resolution * Simplified UI * Drop xpinstall * Switch to sqlite based persistent storage * Dr...) |
No edit summary |
||
| Line 1: | Line 1: | ||
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. | |||
<table border="1"> | |||
<tr> | |||
<td>Description | |||
<td>Priority | |||
<td>Size | |||
<td>Owner | |||
<td>Schedule | |||
<tr> | |||
<td>'''Sqlite storage''' | |||
The current code uses an rdf backend for caching extenstion metadata and state. This should be converted to sqlite. | |||
<td>P1 | |||
<td>L | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''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. | |||
<td>P1 | |||
<td>M | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''[[Firefox:Add-ons Manager UI|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. | |||
<td>P2 | |||
<td>L | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''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. | |||
<td>P2 | |||
<td>S | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''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. | |||
<td>P2 | |||
<td>S | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''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. | |||
<td>P3 | |||
<td>M | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''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. | |||
<td>P3 | |||
<td>M | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''[[Extension Manager:Addon Conflict Resolution|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) | |||
<td>P3 | |||
<td>M | |||
<td> | |||
<td> | |||
<tr> | |||
<td>'''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. | |||
<td>P4 | |||
<td>S | |||
<td> | |||
<td> | |||
</table> | |||