Canmove, confirm
409
edits
Changes
more engine design notes
The AddonManager will support the following APIs:
; installAddonFromSyncDatagetAddonBySyncGUID(syncGUID, callback) : Obtain an add-on from its Sync GUID. Calls the supplied function when that add-on is retrieved. The callback receives null on unknown add-on or the add-on object (generated from the underlying provider) on success. ; installOrUpdateAddonFromSyncData(syncData, syncGUID, callbackObj) : Installs an add-on from sync dataor updates the add-on so it has the information specified. Receives the data from the original add-on, the GUID it should be installed with, and an object describing callbacks to be invoked when specific events occurs. The manager will try to obtain an install record and then execute the install. The callbackObj contains the optional keys *onFailure*, *onInstall*, and *onNewSyncGUID* which can be functions that are called when those events occur. Each function receives *syncData* and *syncGUID* as their first arguments. *onInstall* will additionally receive the newly-created (or existing) add-on record and a boolean indicating whether a restart is required. *onNewSyncGUID* will receive as a 3rd parameter the new syncGUID for the already-installed add-on. As inferred from the callback definition, the function must be able to detect existing add-ons from the *syncData* and update the *syncGUID* of that add-on to the value specified.
; uninstallAddonBySyncGUID(syncGUID, callbackObj) : Uninstalls an add-on specified by its syncGUID. The callbackObj has the optional keys *onSuccess* and *onFailure*. Each receives as an argument the passed *syncGUID*.
Both of these APIs will require the AddonManager to have an additional relationship with the add-on providers (via APIs). The providers will need to provide a routine to install add-ons from *syncData* instances. And, the AddonManager will need to know how to call into these.
The add-ons Sync engine will discover the set of add-ons that can be synced via the following procedure:
# Query AddonManager.getAllAddons()
# Filter the returned list by items that have the *syncData* and *syncGUID* properties and are installed in the profile add-on scope (addon.scope == AddonManager.SCOPE_PROFILE)
The engine will process incoming records via the following procedure:
# Obtain the set of locally-installed add-ons (using above)
# For each incoming record: TODO
The Sync add-on tracker will install add-on listeners in the AddonManager and will listen for the following events:
* onEnabled
* onDisabled
* onInstalled
* onUninstalled
When these are observed, the tracker will:
# Verify the changed add-on is in the set of Sync-able add-ons (using same heuristics as add-on discovery documented above)
# Mark the GUID as changed
# This will result in a new record for that GUID being created automagically. The createRecord() procedure will create the necessary record which will be queued for upload to the Sync server.
On start-up, the add-on engine will query AddonManager.getStartupChanges() for changes applied on application start-up. These are not observed by Sync because they occur before Sync is registered and running. Even if Sync does catch them in its tracker, it should be safe to mark records as changed. The only side-effect will be a slightly different modified time.
AddonManager.getStartupChanges() will be queried for the following change types:
* STARTUP_CHANGE_INSTALLED
* STARTUP_CHANGE_CHANGED
* STARTUP_CHANGE_UNINSTALLED
* STARTUP_CHANGE_DISABLED
* STARTUP_CHANGE_ENABLED
TODO: Sync should catch all startup change events and react to them. We may need an API or some kind of verification/test to ensure newly-introduced startup changes aren't missed by Sync.
}}
{{FeatureInfo
