> Presumably, with this approach, if an older client overwrites the new field, > then nothing bad happens. And we eventually converge on everyone supporting > the new field as clients upgrade.
Old clients will do one of three things: 1. Upload a new record that’s missing fields. New clients will shrug, sigh, and go on with their day. We’ll probably want to have slightly smarter record application logic than usual, to avoid throwing away local data unnecessarily — e.g., if a client record goes from saying it’s a Windows machine to having no opinion, we shouldn’t clear our local platform note. 2. Upload a modified record and preserve the fields. This is only bad if somehow the additional fields should have been updated or invalidated — for example, if an old client changes a password but leaves the old password change timestamp intact. Desktop Sync does scary things like mutate JSON bodies returned from the server, but I don’t think it does so for engine records, so this should not occur. Android doesn’t do such things at all, so it definitely won’t occur there. 3. Barf when processing records with additional fields. I’m confident that this won’t happen on any of our platforms. The primary concern is that this is *very* lossy in a transition period — all existing records, and any record uploaded by an old client, will be missing the fields we’d like them to have. But this is strictly less painful than a version bump, which would throw away existing records and lock out old clients, so we’re taking the best option of a bad bunch. It sounds like we have consensus, so I’ll move forward with bolting bits on to support the work we’re doing. Thanks, all! _______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
