Canmove, confirm
409
edits
Changes
no edit summary
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.)
There are some interesting implications for the design proposed above. AddonManager and providers - not Sync - would be responsible for the format of the records containing add-on metadata and this means the onus of ensuring forwards and backwards compatibility (since e.g. a version 9 client could receive a Sync record from a version 14 client and vice-versa) reside in the AddonManager and providers. This might be new territory for AddonManager and providers. Unfortunately, the alternative means lots of AddonManager-specific code in Sync (at best) or giving up provider agnostic add-on sync (at worst).
}}
{{FeatureInfo
