Just to flesh these points out a little for the record:
> One idea we could do is partition our datatypes. We could turn off and leave > behind an old collection type (say tabs) and only sync a new replacement > collection type (tabs2 or newtabs). This is actually pretty much what bumping a collection version does. A client sees history = 1, writes history = 2, clears the collection, uploads everything again. Clients that don’t support history = 2 refuse to sync history until they upgrade. The flaws with this are: * Someone syncing Nightly against Release, or ESR with whatever, or who are otherwise stranded on an earlier Firefox version, can get in a state of sync not working without knowing why. * Downgrades are a seriously big deal — clients aren’t smart enough to figure out if they can downgrade, so you can try out Nightly and silently end up in a state of *no* devices being able to sync! And Sync 1.5 doesn’t have Reset Sync, so this is totally non-recoverable. * A version upgrade requires uploading all data again, and then downloading it and reconciling it again on every other device. For some collections (bookmarks, history) that’s either impractical or likely to tickle bugs. * On a server move or other wipe event, an old client can upload old data, and the whole dance has to be done again. * Race conditions ho! Those flaws are big enough that we never really used this method, and still don’t plan to. > Another idea is to also ask the server to play a role in data type > negotiation. Perhaps instead of the constellation of clients determining > what datatypes are synced, we have the FxA server intermediate this step. > (This might be part of what ckarlof suggested for the "lightest possible > configuration record”.) Or lightweight client version negotiation: Bug 825731. This requires buy-in from all of the clients in your accounts, though, so that’s a breaking change. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
