Sorry, was away last week. I'm very much in favor of an incremental approach that'll make the longer term goals easier, but I'm aware that for now it's entirely a client resource issue. If you folks can do it, I'm a +1.
Toby On Oct 13, 2014, at 5:50 PM, Richard Newman <[email protected]> wrote: >> 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 > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
