Services/Sync/Features/Addon Sync

From MozillaWiki
< Services‎ | Sync
Revision as of 22:37, 29 August 2011 by Blur (Talk | contribs)

Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Addon Sync
Stage Definition
Status In progress
Release target TBD
Health Blocked
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
Privacy lead `
Localization lead Axel Hecht
Accessibility lead `
QA lead Tracy Walker
UX lead Alex Faaborg
Product marketing lead Jaclyn Fu
Operations lead `
Additional members Ibai Garcia (SUMO)

Open issues/risks


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.

3. Dependencies


4. Requirements




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:

  1. Optional properties on add-on objects that describe the add-on for purposes of use in Sync
  2. 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, and is opaque to Sync code. A JSON representation of an object might be a good choice, to hold the data needed by the add-ons manager to install/uninstall an addon.
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(syncData, syncGUID, callbackObj) 
Installs an add-on from sync data. 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.
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


8. Reviews

Security review


Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation


Stage 5: Release

10. Landing criteria


Feature details

Priority P2
Rank 999
Theme / Goal Experience
Roadmap Sync
Secondary roadmap `
Feature list Services
Project `
Engineering team Sync

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

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