|Status note||Product Management needs to flesh out the feature page so that development can be unblocked.|
|Product manager||Jennifer Arguello|
|Directly Responsible Individual||Jennifer Arguello|
|Lead engineer||Gregory Szorc|
|Security lead||Yvan Boily|
|Localization lead||Axel Hecht|
|QA lead||Tracy Walker|
|UX lead||Alex Faaborg|
|Product marketing lead||Jaclyn Fu|
|Additional members||Ibai Garcia (SUMO)|
Stage 1: Definition
1. Feature overview
Add-ons are synchronized between sync clients.
2. Users & use cases
User installs an add-on on one browser. When a sync occurs, the add-on is automagically installed on other sync clients.
Stage 2: Design
5. Functional specification
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.
The solution to this problem will consist of the following:
- 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
For add-on objects, providers wishing to opt in to Sync will expose the following read-only properties:
- 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.
- 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.
The AddonManager will support the following APIs:
- 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.
- uninstallAddonBySyncGUID(syncGUID, callbackObj)
- Uninstalls an add-on specified by its 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.
6. User experience design
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||Experience|
Team status notes
Discussion notes from 2011-08-16:
- add 'guid' column to 'addon' table in extensions.sqlite
- add GUID support to AddonsManager (have it automatically generated, 12 chars base64url)
- findings addons shouldn't count as daily update pings, or if they do, is it a problem?
- generate one record per app per addon, silently drop records from other apps and unknown addons (unknown to AMO)
- add option to locally disable enabled state sync (the "web developer case") in about:config