Brief reply to this, as I try to preserve the non-working weekend: Sync 1.1 has essentially no upgrade paths. None whatsoever for wire version changes, awful support for adding new engines, and no upgrade mechanism at all that respects durability.
The best it can do is blow away all of your server data and lock out all of the other clients until they upgrade, which was something we weren't willing to do since Firefox 4. (As such, most of the Sync 2.0 "storage format 6" bugs are saved-up improvements that were never worth breaking client compatibility. Sync's data formats haven't changed since 2010.) Assuming a definition of "flag day" as something like "no client interop across this event horizon; upgrade required to continue working", then any change to Sync's wire protocol or storage format would be such a thing. The clients would have no way to negotiate versions, no way to stage storage format changes, etc. etc. Even if we put in all of the expected amount of effort to build a service discovery framework attached to Firefox Account, and switched to a better storage system by using that (deprecate the old, automatically enable the new), it would meet the definition of a flag day because it would partition your devices as they hit the migration point: the old ones wouldn't have client code for the new system, so they couldn't follow the breadcrumbs. (Even worse if we don't ship that service discovery framework in v1!) As I understand the approximate plan of record, we'll be addressing these limitations by replacing the high-level protocol with one that understands protocol and storage versioning and negotiation, with the role of the Sync 1.1 and 2.0 codebases being one of code reuse wherever possible. That way we can rev protocols and storage formats as needed, without unilaterally locking out clients or wiping data. (And our proposed storage protocols -- treesync and queuesync -- both address much of the durability-defeating aspects of both Sync 1.1 and 2.0.) ----- Original Message ----- From: "Andreas Gal" <[email protected]> To: "Brian Warner" <[email protected]> Cc: [email protected] Sent: Friday, August 9, 2013 8:57:30 PM Subject: Re: The Sync 1.1 elephant^H^H^H^H^H^H option Help me understand why we need a second flag day when changing wire formats or storage formats. Andreas Sent from Mobile. On Aug 9, 2013, at 18:02, Brian Warner <[email protected]> wrote: > On 8/9/13 4:37 PM, Lloyd Hilaiel wrote: > >> So I'd like to open a venting thread here. Let's capture once and for >> all the real, actual, user facing or implementation complexity >> downsides of implementing a new authentication flow and grafting it >> onto Sync 1.1. > > I expect rnewman will express this better than I can, but he mentioned > this morning that we basically get one flag day. It's not the super-bad > "everybody must change at the exactly same time" kind of flag day. But > it's a still-kinda-bad "everybody must do a one-way account upgrade > during some multi-month overlap between new-servers-launched and > old-servers-shut-down window" upgrade/flag-day. > > If we use that upgrade to get from Sync1.1+OldAuth to Sync1.1+NewAuth, > we'll land on a system that is known to be fragile, and about which I've > heard scalability/ops problems. To upgrade from there to a more > stable/scalable protocol, we'd need a second flag day, and that'd be too > embarrasing to pull off. > > cheers, > -Brian > _______________________________________________ > 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 _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
