Services/Sync/Features/Addon Sync

Please use "Edit with form" above to edit this page.

Status

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.

{{#set:Feature name=Addon Sync

|Feature stage=Definition |Feature status=In progress |Feature version=TBD |Feature health=Blocked |Feature status note=Product Management needs to flesh out the feature page so that development can be unblocked. }}

Team

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)

{{#set:Feature product manager=Jennifer Arguello

|Feature feature manager=Jennifer Arguello |Feature lead engineer=Gregory Szorc |Feature security lead=Yvan Boily |Feature privacy lead=` |Feature localization lead=Axel Hecht |Feature accessibility lead=` |Feature qa lead=Tracy Walker |Feature ux lead=Alex Faaborg |Feature product marketing lead=Jaclyn Fu |Feature operations lead=` |Feature 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

`

Non-goals

`

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:

syncData

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.

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.

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. The callbackObj contains the optional keys *onFailure*, *onInstall*, and *onNewSyncGUID* which can be functions that are called when those events occur. Each function receives *syncData* and *syncGUID* as their first arguments. *onInstall* will additionally receive the newly-created (or existing) add-on record and a boolean indicating whether a restart is required. *onNewSyncGUID* will receive as a 3rd parameter the new syncGUID for the already-installed add-on. As inferred from the callback definition, the function must be able to detect existing add-ons from the *syncData* and update the *syncGUID* of that add-on to the value specified.

uninstallAddonBySyncGUID(syncGUID, callbackObj)

Uninstalls an add-on specified by its syncGUID. The callbackObj has the optional keys *onSuccess* and *onFailure*. Each receives as an argument the passed *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

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |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 dependencies=` |Feature requirements=` |Feature non-goals=` |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.

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:

syncData

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.

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.

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. The callbackObj contains the optional keys *onFailure*, *onInstall*, and *onNewSyncGUID* which can be functions that are called when those events occur. Each function receives *syncData* and *syncGUID* as their first arguments. *onInstall* will additionally receive the newly-created (or existing) add-on record and a boolean indicating whether a restart is required. *onNewSyncGUID* will receive as a 3rd parameter the new syncGUID for the already-installed add-on. As inferred from the callback definition, the function must be able to detect existing add-ons from the *syncData* and update the *syncGUID* of that add-on to the value specified.

uninstallAddonBySyncGUID(syncGUID, callbackObj)

Uninstalls an add-on specified by its syncGUID. The callbackObj has the optional keys *onSuccess* and *onFailure*. Each receives as an argument the passed *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. |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

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

{{#set:Feature priority=P2

|Feature rank=999 |Feature theme=Experience |Feature roadmap=Sync |Feature secondary roadmap=` |Feature list=Services |Feature project=` |Feature engineering team=Sync }}

Team status notes

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

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations 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