Canmove, confirm
409
edits
Changes
no edit summary
; getAddonBySyncGUID(syncGUID, callback) : Obtain an add-on from its Sync GUID. Calls the supplied function when that add-on is retrieved. The callback receives null on unknown add-on or the add-on object (generated from the underlying provider) on success. This API technically isn't required, but it makes the Sync code smaller by pushing out logic and possibly caching.
; applySyncRecordsapplyRecords(records, callbackObj) : This applies an array of records that contain add-on metadata and makes the current state of the world agree with that data as much as possible.
The callbackObj is an object containing the following optional keys:
* isDeleted (optional) - If evaluates to true, indicates that the record was deleted. Application of this record should involve trying to delete this add-on if present or no-op if not present.
The implementation of applySyncRecordsapplyRecords() will resemble the following pseudocode:
<pre>
#* Open Issue: Should the AddonManager do this filtering? Should the add-on providers only expose syncData on add-ons installed in the proper location?
The engine will process incoming records by converting them to the API accepted by AddonManager.applySyncRecordsapplyRecords() and 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:
