Canmove, confirm
409
edits
Changes
documenting possible record choices
|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: * Add-ons are only synchronized between similar client types clients of the same application ID (e.g. Firefox desktop and , mobile, or Thunderbird). In other wordsThe 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. This leads to some interesting choices with regards to the add-on set for desktop clients is independent of of that of mobiledata record. The reason We have the following approaches for this is record modeling: # Per add-on records# Per { add-on, application type } pair# Per client records Per per add-on compatibility. At records would likely resemble the time this was writtenfollowing: ADDON_GUID = { clients: { A: { install_state: "INSTALLED", most enabled: true, type: "desktop", }, B: { install_state: "UNINSTALLED", type: "mobile" } } } For per add-ons did not function properly on /application type, we would have: ADDON_GUID-DESKTOP = { addons: { A: { install_state: "INSTALLED", enabled: true }, B: { install_state: "UNINSTALLED", type: "mobile" } }, other_prefs: undefined } And for per-client records, we would have: CLIENT_ID = { app_type: "desktop.", addons: { ADDON1: { install_state: "installed", enabled: true, }, ADDON2: { install_state: "uninstalled", }, ADDON3: { install_state: "installed", enabled: false } }, other_prefs: undefined }
}}
{{FeatureInfo
