Extension Manager:API Rewrite
Overview
The current extension manager API is focussed on managing XPI style add-ons and is currently very limited forcing the UI and other callers to rely on direct access to the RDF datastore to glean required information about add-ons.
The main goals of this rewrite are:
- Support a wider range of add-on types managed through the same API
- Allow application/extension developers to be able to easily query the state of installed items
- Make it easier for applications to replace the add-ons UI with their own implementation by making all necessary information available through the defined API
- Remove direct access to the datastore
High Level View
The new API is accessed through a global AddonManager object that is included in a JavaScript module. There will also be a limited amount of access provided through an XPCOM component but this is intended for the XRE to use during startup. The API makes no assumptions about what different types of add-ons do and how they are used, it does make some basic assumptions about the information available about them and the install process. Users of the API can register to receive events about all add-ons.
Add-on Providers
Underneath the manager (and essentially invisible through the API) are a set of add-on providers. Each one manages a specific type of add-on, for example there can be a provider for XPI style add-ons, a provider for plugins, a provider for lightweight themes, etc. There will probably be a hardcoded set of providers for the application and then some means for add-ons to register their own providers. It is up to the providers to maintain their lists of installed add-ons, perform installation and uninstallation and send appropriate notifications out to registered listeners.
Addon
The Addon object represents an add-on that is installed on the local system. This is a loose term since it also includes add-ons that have been downloaded and will be installed when the application is restarted. It is possible that the API will hand out multiple instances of Addon for the same underlying add-on. There are a set of properties that will be available for all types of add-ons and then each type of add-on may have additional properties. The same goes for operations that can be performed on the add-on.
Certain add-ons may have restrictions over what operations can be performed. These restrictions could be just down to the nature of the add-on (themes cannot be disabled normally) or down to system policies (user's may not have access to uninstall some add-ons f.e.). Each Addon has a permissions property that indicates what operations can currently be performed.
Some types of add-ons may require restarts for certain operations. XPI style extensions for example require restarts for almost all operations. The API exposes the operations that are pending in the pendingOperations property. It is also possible that this property may be used to indicate operations that have been deferred for any reason, maybe timing issues, maybe a dependency is pending install. Pending operations can make it hard to tell what state an actual add-on is in. To help solve this the isActive property indicates whether the add-on is currently active. This is separate to and may be different to the various userDisabled, isCompatible and other properties that indicate whether an add-on can be active or not.
Addon objects are live views of the underlying add-on. The properties are always guaranteed to be up to date.
AddonInstall
The AddonInstall object represents an add-on that is not yet installed or has just been installed. It may come from an update check to an existing add-on, a request to install a new add-on or a search for new add-ons. It tracks the high level progress of any necessary downloads, dependencies and installation of the add-on.
The AddonInstall goes through a set of states:
- Available
- Represents an add-on that is known to be available for install. Depending on where the AddonInstall came from there may be very little information about the add-on available.
- Downloading
- This state is used to show that downloads are in progress for the add-on. Almost all add-ons consist of a single file to download. Once the file is downloaded the Checking state may be entered if additional information is required, otherwise the Downloaded state is entered.
- Checking
- In some cases the additional information about version compatibility and dependencies may be required. The Checking state is used for small lookup requests for these and then dependent on the result the AddonInstall may move back to the Downloading state or on to the Downloaded state.
- Downloaded
- At this point all the necessary parts of the add-on are available on the computer. It is here that the user may be asked if they want to proceed with the installation.
- Installing
- Here the add-on is being installed by its provider. This may cover file extraction etc.
- Installed
- Here the add-on has been installed and its Addon object will appear in AddonManager.getAddons. The add-on itself however may not be active until after an application restart.
Once the install process for an AddonInstall is started with startInstall it will move through all of the states naturally sending out notifications at each transition and some progress events in between until either an error is encountered or the install is stopped by calling stopInstall or the install completes successfully.
Certain types on installs may skip steps. Installing an add-on from the file system for example may jump straight to the Downloaded (or Checking) state since there is no need to download it.
Dependencies and Bootstrapping
It is anticipated that at some time automatic downloading of dependencies and bootstrap add-ons will be implemented. This is intended to happen in the AddonInstall Downloading and Checking states. Once the initial file for an add-on is downloaded the AddonManager checks to see if a repository is installed to handle it.
If there is a repository to handle the add-on then it is used to check for compatibility, updates and dependency information. And dependent items will be downloaded before the AddonInstall moves to the Downloaded state, allowing the item to be installed and usable with minimal delay after that point.
If there is no repository to handle the add-on then some form of bootstrapping mechanism will be used to find and add-on that contains a repository to handle the new add-on. As an example we may have a means to detect that the file is a zip file containing a manifest.json file which would suggest we should download the Jetpack runtime and install it.