Extension Manager:Future Work: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(3 intermediate revisions by the same user not shown)
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.
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.


<table border="1">
The following points should be noted when reading this plan:
<tr>
* It only lists the "big ticket" items. Other fixes will be ongoing in parallel to these.
  <td>Description
* 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).
  <td>Priority
* The timescales and plans are all subject to change, hopefully this page will be kept updated as changes are made.
  <td>Size
 
  <td>Owner
=High Level Roadmap=
  <td>Schedule
 
<tr>
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.
  <td>'''Sqlite storage'''
 
The current code uses an rdf backend for caching extenstion metadata and state. This should be converted to sqlite.
[[Image:User-Mossop-EM_Goals-Plan.png|680px]]
  <td>P1
 
  <td>L
The timescales are only rough guesses at this point based on two people doing the bulk of the implementation and reviews.
  <td>
 
  <td>
=Target Audiences=
<tr>
 
  <td>'''Install add-ons without restart'''
Changes to the extension manager have varying target audiences. Most goals should be relevant to at least one of the following audiences:
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
* Application users
  <td>M
* Application developers
  <td>
* Add-on developers
  <td>
 
<tr>
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.
  <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.
=Planned Goals=
  <td>P2
 
  <td>L
==EM-001 API Improvements==
  <td>
 
  <td>
'''References:''' [[Extension Manager:Sqlite Storage#API|Draft Specification]], {{Bug|461973}}
<tr>
 
  <td>'''Drop XPInstall'''
'''Target Audience:''' None
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
'''Requires:''' Nothing
  <td>S
 
  <td>
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.
  <td>
 
<tr>
==EM-002 SQLite Backend==
  <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.
'''References:''' [[Extension Manager:Sqlite Storage|Draft Specification]], {{Bug|449585}}
  <td>P2
 
  <td>S
'''Target Audience:''' None
  <td>
 
  <td>
'''Requires:''' EM-001
<tr>
 
  <td>'''Blocklist plugins by file version'''
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.
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.
 
  <td>P2
==EM-003 User Interface Reorganisation==
  <td>S
 
  <td>
'''References:''' [[Firefox:Add-ons Manager UI|Draft Specification]], {{Bug|397581}}
  <td>
 
<tr>
'''Target Audience:''' Application users, Application developers
  <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.
'''Requires:''' EM-001
  <td>P3
 
  <td>M
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.
  <td>
 
  <td>
==EM-004 Install/Uninstall Hooks==
<tr>
 
  <td>'''Split out the startup code'''
'''References:''' [[Extension Manager:Install Hooks|Draft Specification]] {{Bug|416246}}
We can defer loading of the main component until it is really needed which for the majority of startups is never.
 
  <td>P3
'''Target Audience:''' Add-on developers
  <td>M
 
  <td>
'''Requires:''' Nothing
  <td>
 
<tr>
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.
  <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)
==EM-005 Install Without Restart==
  <td>P3
 
  <td>M
'''References:''' {{Bug|256509}}
  <td>
 
  <td>
'''Target Audience:''' Application users
<tr>
 
  <td>'''Sandboxing extension code'''
'''Requires:''' EM-004
It would be nice to be able to sandbox certain extensions so they don't have certain privileges like writing to the local disk.
 
  <td>P3
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.
  <td>?
 
  <td>
==EM-006 Replace RDF Formats==
  <td>
 
<tr>
'''References:''' [[Extension Manager:Replace RDF|Draft Specification]], {{Bug|461975}}
  <td>'''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.
'''Target Audience:''' Add-on developers
  <td>P4
 
  <td>S
'''Requires:''' Nothing
  <td>
 
  <td>
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.  
<tr>
 
  <td>'''Improve blocklist interaction with plugin host'''
==EM-007 Application Specific Metadata==
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
 
  <td>P4
'''References:''' {{Bug|461976}}
  <td>S
 
  <td>
'''Target Audience:''' Application developers
  <td>
 
<tr>
'''Requires:''' EM-002
  <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.
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.
  <td>P4
 
  <td>S
==EM-008 Add-on Dependency Resolution==
  <td>
 
  <td>
'''References:''' [[Extension Manager:Addon Conflict Resolution|Outdated specification]] {{Bug|345610}}
<tr>
 
  <td>'''Replace install/update.rdf'''
'''Target Audience:''' Add-on developers
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.
 
  <td>P4
'''Requires:''' Nothing
  <td>S
 
  <td>
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.
  <td>
 
</table>
=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.

Latest revision as of 10:23, 30 March 2009

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.

User-Mossop-EM Goals-Plan.png

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.

Retrieved from "https://wiki.allizom.org/index.php?title=Extension_Manager:Future_Work&oldid=136953"