Services/Sync/Features/Addon Sync: Difference between revisions
(current info) |
(move decided open issues) |
||
Line 22: | Line 22: | ||
<td>Issue/Risk</td> | <td>Issue/Risk</td> | ||
<td>Status</td> | <td>Status</td> | ||
</tr> | </tr> | ||
<tr valign="top"> | <tr valign="top"> | ||
Line 137: | Line 121: | ||
}} | }} | ||
{{FeatureTeamStatus | {{FeatureTeamStatus | ||
|Feature products notes= | |Feature products notes=; Update syncing cut : Syncing on add-on update is cut because an updating mechanism is already part of Firefox. I will follow up with FF folks to see if Sync does bring value. We can address it later. | ||
; Only sync between the same application : Add-ons will initially only sync between applications of the same application ID. This is because most add-ons aren't compatible across different applications. | |||
}} | }} | ||
Discussion notes from 2011-08-16: | Discussion notes from 2011-08-16: |
Revision as of 17:45, 4 November 2011
Status
Addon Sync | |
Stage | Development |
Status | In progress |
Release target | TBD |
Health | OK |
Status note | Development is in progress. |
{{#set:Feature name=Addon Sync
|Feature stage=Development |Feature status=In progress |Feature version=TBD |Feature health=OK |Feature status note=Development is in progress. }}
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 | ` |
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=` |Feature product marketing lead=Jaclyn Fu |Feature operations lead=` |Feature additional members=Ibai Garcia (SUMO) }}
Open issues/risks
Issue/Risk | Status |
Do we need some prompts or feedback when add-ons are synced, at all? |
Probably. Many add-ons still aren't restartless, so installing, uninstalling, enabling, or disabling will require restart. When Sync is driving the add-on install, the Add-on Manager won't display any visual prompts. So, it will be Sync's responsibility to trigger a UI element to prompt restart, if desired. Sync has full control over that element. We could display the one used by the Add-on Manager or make our own.
|
Are there any problems with large sets of add-on state being updated at once? Say the user has not used a device for a while and they use it again and a whole bunch of add-ons need to be updated. |
Stage 1: Definition
1. Feature overview
Sync is a service to keep the Firefox experience consistent across multiple devices by ensuring user data is synced across various devices. This feature will enable add-ons to be synced across devices. Add-ons are small pieces of software that add new features or functionality to an installation of Firefox. Add-ons can augment Firefox with new features, foreign language dictionaries, or change its visual appearance. Through add-ons, you can customize Firefox to meet your needs and tastes.
Sync will ensure that add-ons are installed, uninstalled, disabled,and enabled as they are changed on each client for the same application. This means that desktop to desktop add-ons will sync, and mobile to mobile add-ons will sync.
For the initial release, only XPI extensions and themes from addons.mozilla.org will be supported. In a future release, we can expand scope to add-ons not from addons.mozilla.org.
2. Users & use cases
- Desktop browser to browser add-on install
- A user has sync set up his work and home desktops
- He goes to AMO and installs an add-on on his work computer
- When he goes home and starts his Firefox browser the new add-on will be usable and shows up in the add-on tab
- Desktop browser to browser add-on uninstall
- A user has sync set up his work and home desktops
- At work, he goes to the add-on tab in the browser and removes the add-on
- When he goes home and starts his Firefox browser this add-on will remove itself and not show up in the add-on tab
- Desktop browser to browser add-on disable
- A user has sync set up his work and home desktops
- At work, he goes to the add-on tab in the browser and disables an add-on
- When he goes home and starts his Firefox browser this add-on will disable itself and not show up in the add-on tab
- Desktop browser to browser add-on enable
- A user has sync set up his work and home desktops
- At work, he goes to the add-on tab in the browser and enables a disabled add-on
- When he goes home and starts his Firefox browser this add-on will enable itself and not show up in the add-on tab
3. Dependencies
- Sync GUID added to XPI Provider
- Sync requires non-deterministic IDs to be affiliated with synchronized records. XPI add-ons currently don't have a suitable ID so once will need to be created.
4. Requirements
- When a user installs an add-on, the add-on will be installed on all the user's devices connected with Sync.
- When a user uninstalls an add-on, the add-on will be uninstalled on all the user's devices connected with Sync
- When a user disables an add-on, the add-on will be disabled on all the user's devices connected with Sync
- When a user enables an add-on, the add-on will be enabled on all the user's devices connected with Sync
- Not sure about the update version requirement.
- Non-impact on add-on manager metrics
- The presence of Sync should not skew the metrics in the add-on manager and addons.mozilla.org. Currently, some APIs on the AddonManager upload metrics.
Non-goals
- Syncing add-on information across different Application IDs
- Sync will not synchronize non-XPI add-ons such as plugins, lightweight themes, and search engines. Sync will also not synchronize add-ons installed outside of the currently running profile.
Stage 2: Design
5. Functional specification
Like other browser primitives that have become syncified, the underlying entities being synced will need a sync identifier. bug 682027 tracks adding a syncGUID to the extensions SQLite database. This properties will need to be documented at https://developer.mozilla.org/en/Addons/Add-on_Manager/Addon.
New APIs will be added to the AddonManager as appropriate.
TODO: we should formalize how the Sync engine gets informed of whether a restart is required to finish the record application. Do we catch this in the tracker observers or install observers local to the sync method of the engine?
The add-ons Sync engine will discover the set of add-ons that can be synced via the following procedure:
- Query AddonManager.getAllAddons()
- Filter the returned list by items that are appropriate for sync
The Sync add-on tracker will install add-on listeners in the AddonManager and will listen for the following events:
- onEnabled
- onDisabled
- onInstalled
- onUninstalled
When these are observed, the tracker will:
- Verify the changed add-on is in the set of Sync-able add-ons (using same heuristics as add-on discovery documented above, if needed)
- Mark the GUID as changed
- This will result in a new record for that GUID being created automagically. The createRecord() procedure will in turn create the necessary record by querying AddonManager which will be queued for upload to the Sync server.
On start-up, the add-on engine will query AddonManager.getStartupChanges() for changes applied on application start-up. These are not observed by Sync because they occur before Sync is registered and running. Even if Sync does catch them in its tracker, it should be safe to mark records as changed. The only side-effect will be a slightly different modified time.
AddonManager.getStartupChanges() will be queried for the following change types:
- STARTUP_CHANGE_INSTALLED
- STARTUP_CHANGE_CHANGED
- STARTUP_CHANGE_UNINSTALLED
- STARTUP_CHANGE_DISABLED
- STARTUP_CHANGE_ENABLED
TODO: Sync should catch all startup change types (the constants above) and react to them. We may need an API or some kind of verification/test to ensure newly-introduced startup changes/constants aren't missed by Sync. (This is all because getStartupChanges() requires a type as a parameter.)
6. User experience design
- May need some for giving the user feedback when an add-on is being updated due to sync.
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=
Issue/Risk | Status |
Do we need some prompts or feedback when add-ons are synced, at all? |
Probably. Many add-ons still aren't restartless, so installing, uninstalling, enabling, or disabling will require restart. When Sync is driving the add-on install, the Add-on Manager won't display any visual prompts. So, it will be Sync's responsibility to trigger a UI element to prompt restart, if desired. Sync has full control over that element. We could display the one used by the Add-on Manager or make our own.
|
Are there any problems with large sets of add-on state being updated at once? Say the user has not used a device for a while and they use it again and a whole bunch of add-ons need to be updated. |
|Feature overview=Sync is a service to keep the Firefox experience consistent across multiple devices by ensuring user data is synced across various devices. This feature will enable add-ons to be synced across devices. Add-ons are small pieces of software that add new features or functionality to an installation of Firefox. Add-ons can augment Firefox with new features, foreign language dictionaries, or change its visual appearance. Through add-ons, you can customize Firefox to meet your needs and tastes.
Sync will ensure that add-ons are installed, uninstalled, disabled,and enabled as they are changed on each client for the same application. This means that desktop to desktop add-ons will sync, and mobile to mobile add-ons will sync.
For the initial release, only XPI extensions and themes from addons.mozilla.org will be supported. In a future release, we can expand scope to add-ons not from addons.mozilla.org. |Feature users and use cases=; Desktop browser to browser add-on install
- A user has sync set up his work and home desktops
- He goes to AMO and installs an add-on on his work computer
- When he goes home and starts his Firefox browser the new add-on will be usable and shows up in the add-on tab
- Desktop browser to browser add-on uninstall
- A user has sync set up his work and home desktops
- At work, he goes to the add-on tab in the browser and removes the add-on
- When he goes home and starts his Firefox browser this add-on will remove itself and not show up in the add-on tab
- Desktop browser to browser add-on disable
- A user has sync set up his work and home desktops
- At work, he goes to the add-on tab in the browser and disables an add-on
- When he goes home and starts his Firefox browser this add-on will disable itself and not show up in the add-on tab
- Desktop browser to browser add-on enable
- A user has sync set up his work and home desktops
- At work, he goes to the add-on tab in the browser and enables a disabled add-on
- When he goes home and starts his Firefox browser this add-on will enable itself and not show up in the add-on tab
|Feature dependencies=; Sync GUID added to XPI Provider : Sync requires non-deterministic IDs to be affiliated with synchronized records. XPI add-ons currently don't have a suitable ID so once will need to be created. |Feature requirements=*When a user installs an add-on, the add-on will be installed on all the user's devices connected with Sync.
- When a user uninstalls an add-on, the add-on will be uninstalled on all the user's devices connected with Sync
- When a user disables an add-on, the add-on will be disabled on all the user's devices connected with Sync
- When a user enables an add-on, the add-on will be enabled on all the user's devices connected with Sync
- Not sure about the update version requirement.
- Non-impact on add-on manager metrics
- The presence of Sync should not skew the metrics in the add-on manager and addons.mozilla.org. Currently, some APIs on the AddonManager upload metrics.
|Feature non-goals=;Syncing add-on information across different Application IDs
- Sync will not synchronize non-XPI add-ons such as plugins, lightweight themes, and search engines. Sync will also not synchronize add-ons installed outside of the currently running profile.
|Feature functional spec=Like other browser primitives that have become syncified, the underlying entities being synced will need a sync identifier. bug 682027 tracks adding a syncGUID to the extensions SQLite database. This properties will need to be documented at https://developer.mozilla.org/en/Addons/Add-on_Manager/Addon.
New APIs will be added to the AddonManager as appropriate.
TODO: we should formalize how the Sync engine gets informed of whether a restart is required to finish the record application. Do we catch this in the tracker observers or install observers local to the sync method of the engine?
The add-ons Sync engine will discover the set of add-ons that can be synced via the following procedure:
- Query AddonManager.getAllAddons()
- Filter the returned list by items that are appropriate for sync
The Sync add-on tracker will install add-on listeners in the AddonManager and will listen for the following events:
- onEnabled
- onDisabled
- onInstalled
- onUninstalled
When these are observed, the tracker will:
- Verify the changed add-on is in the set of Sync-able add-ons (using same heuristics as add-on discovery documented above, if needed)
- Mark the GUID as changed
- This will result in a new record for that GUID being created automagically. The createRecord() procedure will in turn create the necessary record by querying AddonManager which will be queued for upload to the Sync server.
On start-up, the add-on engine will query AddonManager.getStartupChanges() for changes applied on application start-up. These are not observed by Sync because they occur before Sync is registered and running. Even if Sync does catch them in its tracker, it should be safe to mark records as changed. The only side-effect will be a slightly different modified time.
AddonManager.getStartupChanges() will be queried for the following change types:
- STARTUP_CHANGE_INSTALLED
- STARTUP_CHANGE_CHANGED
- STARTUP_CHANGE_UNINSTALLED
- STARTUP_CHANGE_DISABLED
- STARTUP_CHANGE_ENABLED
TODO: Sync should catch all startup change types (the constants above) and react to them. We may need an API or some kind of verification/test to ensure newly-introduced startup changes/constants aren't missed by Sync. (This is all because getStartupChanges() requires a type as a parameter.) |Feature ux design=;May need some for giving the user feedback when an add-on is being updated due to sync. |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 | ` | ; Update syncing cut : Syncing on add-on update is cut because an updating mechanism is already part of Firefox. I will follow up with FF folks to see if Sync does bring value. We can address it later.
|
Engineering | ` | ` |
Security | ` | ` |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=; Update syncing cut : Syncing on add-on update is cut because an updating mechanism is already part of Firefox. I will follow up with FF folks to see if Sync does bring value. We can address it later.
- Only sync between the same application
- Add-ons will initially only sync between applications of the same application ID. This is because most add-ons aren't compatible across different applications.
|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