|Feature overview=Add-ons are synchronized between sync clients.
|Feature users and use cases=User installs an add-on on one browser. When a sync occurs, the add-on is automagically installed on other sync clients.
|Feature functional spec=Let's assume the following feature set:The Addon Manager maintainers would like to see Sync support all add-on providers so as to not introduce 1st and 2nd class providers. This will require some APIs.
* Add-ons are only synchronized between clients The solution to this problem will consist of the same application ID (e.g. Firefox desktop, mobile, or Thunderbird). The reason is compatibility. Most add-ons simply don't work across multiple application types.* Given the above, we still need to support syncing add-ons installed on multiple application types.following:
This leads to some interesting choices with regards to # Optional properties on add-on objects that describe the add-on data record. We have the following approaches for record modeling:purposes of use in Sync# Functions on AddonManager that take above properties and perform actions
# Per For add-on records# Per { addobjects, providers wishing to opt in to Sync will expose the following read-on, application type } pair# Per client recordsonly properties:
Per per ; syncData : a string that describes data necessary to synchronize the add-on records would likely resemble between clients. The format of the following:string is not defined. A JSON representation of an object might be a good choice.
ADDON_GUID = { clients; syncGUID : { A: { install_state: "INSTALLED", enabled: true, type: "desktop", }, B: { install_state: "UNINSTALLED", type: "mobile" } } }a GUID used to identify this add-on across Sync client instances. The GUID should be generated using Utils.makeGUID() from the Sync code. It is basically a Base64-encoded representation of 9 random bytes.
For per add-on/application type, we would haveThe AddonManager will support the following APIs:
ADDON_GUID-DESKTOP = { addons: { A: { install_state: "INSTALLED"; installAddonFromSyncData(type, syncGUID, syncData, enabledcallbackObj) : true }Installs an add-on from sync data. Receives the add-on type, B: { install_state: "UNINSTALLED"the GUID it should be installed with, type: "mobile" } }the data from the original add-on, other_prefs: undefined }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.
And for per-client records; uninstallAddonBySyncGUID(syncGUID, we would havecallbackObj) :Uninstalls an add-on specified by its syncGUID.
CLIENT_ID = { app_type: "desktop"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, addons: { ADDON1: { install_state: "installed", enabled: true, }, ADDON2: { install_state: "uninstalled", }, ADDON3: { install_state: "installed", enabled: false } }, other_prefs: undefined }the AddonManager will need to know how to call into these.
}}
{{FeatureInfo
