Extension Manager:API Rewrite: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 10: Line 10:


=High Level View=
=High Level View=
The new API is accessed through a global [[Extension Manager:API Rewrite:API#AddonManager|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 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.
The new API is accessed through a global [[Extension Manager:API Rewrite:API#AddonManager|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.


Users of the API can register to receive events about all add-ons. The API also gives access to two main types of objects:
==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==
==Addon==
Line 36: Line 37:


Once the install process for an AddonInstall is started with <code>startInstall</code> 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 <code>stopInstall</code> or the install completes successfully.
Once the install process for an AddonInstall is started with <code>startInstall</code> 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 <code>stopInstall</code> or the install completes successfully.
==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 (perhaps multiple providers for each type of XPI add-on but that's unlikely), 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.
The new APIs represent add-ons in a number of states but these can broadly be split into two types, Local add-ons and Available add-ons. The API objects representing these add-ons are considered live views of the add-on. As operations are performed (disabling, downloading etc.) the properties of the object will update to reflect the new state. The objects represent add-on instances however. If I have an object representing the installed add-on "foo", then the user uninstalls and then reinstalls "foo" then the object still represents the old uninstalled instance of "foo". It is undefined whether retrieving the same add-on from the API twice will give two references to the same object or two separate objects that have the same properties.
canmove, Confirmed users
1,570

edits

Navigation menu