canmove, Confirmed users
409
edits
Services/Sync/Features/Addon Sync: Difference between revisions
Services/Sync/Features/Addon Sync (view source)
Revision as of 00:11, 31 August 2011
, 31 August 2011no edit summary
No edit summary |
No edit summary |
||
| Line 121: | Line 121: | ||
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.) | 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 | {{FeatureInfo | ||