In a recent chat with the Metrics team, I learned that a very large percentage of our heavy users are on the most recent Firefox version (duh, that’s what I would hope).
Yes, incrementally change the shit out of Sync storage formats. -chris On Mon, Oct 20, 2014 at 11:15 AM, Toby Elliott <telli...@mozilla.com> wrote: > 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 <rnew...@mozilla.com> 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 > > Sync-dev@mozilla.org > > https://mail.mozilla.org/listinfo/sync-dev > >
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
