|
|
| Line 75: |
Line 75: |
|
| |
|
| ;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. | | ;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. | | |Feature functional spec=A syncGUID field has been added to the extensions SQLite database ({{bug|682027}}. All extensions now have a randomly-generated ID suitable for syncing. |
|
| |
|
| New APIs will be added to the AddonManager as appropriate.
| | To track changes, Sync has written a component outside of the add-ons engine called the "Add-ons Reconciler." This provides what the Add-on Manager does not: a persisted state of add-on changes and limited state. It installs itself as a listener for Add-on Manager events. When things changed, it records that change and updates it's own minimal copy of the global state. These changes are persisted to disk in a JSON file file in the profile directory. |
|
| |
|
| 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 engine subscribes to changes in the Add-on Reconciler to trigger instant sync. At the beginning of every sync, Sync asks the reconciler to reconcile its state with the world. Then, it sees all that has changed since the last sync and pushes out sync records, as appropriate. |
| | | |Feature ux design=UX has stated that there will be no new UX for this feature. Individual add-ons may trigger UX when they are modified, but there is nothing we can do about that. |
| 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.)
| |
| | |
| The first release will not include locales & dictionaries. follow up bugs have been filed.
| |
| |Feature ux design=;May need some for giving the user feedback when an add-on is being updated due to sync. | |
| |Feature security review=The feature follows the same security model as other sync engines: add-on records are encrypted using the Sync Key and the IDs for each add-on are randomly generated. | | |Feature security review=The feature follows the same security model as other sync engines: add-on records are encrypted using the Sync Key and the IDs for each add-on are randomly generated. |
|
| |
|