Services/Sync/Features/Addon Sync: Difference between revisions

Services/Sync/Features/Addon Sync (view source)

Revision as of 01:31, 30 August 2011

213 bytes added , 30 August 2011

refactor implementation

Gszorc

canmove, Confirmed users

409

edits

@@ Line 21: / Line 21: @@
 |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:
+|Feature functional spec=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 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.
+The solution to this problem will consist of the following:
-* Given the above, we still need to support syncing add-ons installed on multiple application types.
-This leads to some interesting choices with regards to the add-on data record. We have the following approaches for record modeling:
+# Optional properties on add-on objects that describe the add-on for purposes of use in Sync
+# Functions on AddonManager that take above properties and perform actions
-# Per add-on records
+For add-on objects, providers wishing to opt in to Sync will expose the following read-only properties:
-# Per { add-on, application type } pair
-# Per client records
-Per per add-on records would likely resemble the following:
+; syncData : a string that describes data necessary to synchronize the add-on between clients. The format of the string is not defined. A JSON representation of an object might be a good choice.
- ADDON_GUID = {
+; syncGUID : 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.
-   clients: {
-     A: {
-       install_state: "INSTALLED",
-       enabled: true,
-       type: "desktop",
-     },
-     B: {
-       install_state: "UNINSTALLED",
-       type: "mobile"
-     }
-   }
- }
-For per add-on/application type, we would have:
+The AddonManager will support the following APIs:
- ADDON_GUID-DESKTOP = {
+; installAddonFromSyncData(type, syncGUID, syncData, callbackObj) : Installs an add-on from sync data. Receives the add-on type, the GUID it should be installed with, the data from the original add-on, 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.
-   addons: {
-     A: {
-      install_state: "INSTALLED",
-      enabled: true
-     },
-     B: {
-       install_state: "UNINSTALLED",
-       type: "mobile"
-     }
-   },
-   other_prefs: undefined
- }
-And for per-client records, we would have:
+; uninstallAddonBySyncGUID(syncGUID, callbackObj) : Uninstalls an add-on specified by its syncGUID.
-  CLIENT_ID = {
+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.
-    app_type: "desktop",
-    addons: {
-      ADDON1: {
-        install_state: "installed",
-        enabled: true,
-      },
-      ADDON2: {
-        install_state: "uninstalled",
-      },
-      ADDON3: {
-        install_state: "installed",
-        enabled: false
-      }
-    },
-    other_prefs: undefined
-  }
 }}
 {{FeatureInfo

Services/Sync/Features/Addon Sync: Difference between revisions

Services/Sync/Features/Addon Sync (view source)

Revision as of 01:31, 30 August 2011

Navigation menu

Search