825731 - [meta] Per-engine storage version negotiation

Status: RESOLVED INCOMPLETE

(Cloud Services :: General, defect)

Description

[Richard Newman [:rnewman]]

If we take a dependency on thorough device management (not Sync 1.1 style, because we need to reliably detect removals), and extend clients to have a notion of version ranges, then we can narrow users' exposure to version conflicts. Clients would ship with a set of engine versions, and at runtime they would negotiate which version to use.

When you've upgraded every device in your sync constellation to a version that speaks, say, bookmarks-7, they all switch from bookmarks-6. If you then try to connect a device that only speaks bookmarks-5 and bookmarks-6, it'll have no choice but to report that it's too old to sync your bookmarks. But for a stable set of devices following a usual upgrade path, there would be seamless support.

This avoids alternative schemes (such as parallel data management to allow clients to interoperate across versions) by instead explicitly having clients describe their capabilities and negotiate a format.

Like any multi-version system, this will accrue a significant amount of code complexity, testing overhead, support complexity ("which versions are you using?"), and bug surface area (the need to fix bugs in every supported version, and also the possibility that users wouldn't be running fixed code due to an old client). But this will unlock our schedule, allowing us to fix storage-related issues (including Bug 745408) without incurring version mismatches.

Filing this as a meta bug, because there'll be implementations for each client.

Comments on this proposal, folks?

Comment 1

[Ryan Kelly [:rfkelly]]

I'm very confident that we're not going to get around to this.  Mentat or bust!