Changes

Jump to: navigation, search

Services/Sync/Features/Addon Sync

622 bytes removed, 22:55, 30 August 2011
no edit summary
# Filter the returned list by items that have the *syncData* and *syncGUID* properties and are installed in the profile add-on scope (addon.scope == AddonManager.SCOPE_PROFILE)
The engine will process incoming records via by converting them to the following procedure: # Obtain the set of locally-installed add-ons API accepted by AddonManager.applySyncRecords(using above)# For each incoming record: TODOand will invoke that function with them. This is similar to how the history engine works.
The Sync add-on tracker will install add-on listeners in the AddonManager and will listen for the following events:
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() takes a type as a parameter.)
 
Open Issues:
 
* What's the best way to reconcile installed add-ons with different Sync GUIDs? This will happen when two clients have installed the same add-on on different clients and then sets up Sync. The first Sync client will upload the records. Then, the 2nd will download that set and apply them. Should the Sync engine query AddonManager to see which add-ons (from the opaque *syncData* field) are not present or just call out into AddonManager and have it automagically recognize the dupe and update the Sync GUID? Either way, the Sync engine will need to know which Sync GUID disappeared so it can create a record saying the add-on was deleted/updated.
}}
{{FeatureInfo
Canmove, confirm
409
edits

Navigation menu