Concurrent modifications happen (both from user input and due to user activity), and a system not specifically designed to address this (and races, and offlining, and other kinds of timing/conflict issues) will *at sufficient usage* suffer from a background hum of user dissatisfaction.
You're specifically proposing that we build and ship a system we *know* to be less reliable than Firefox Sync, just to get to market sooner and move some complexity around. I don't think avoiding domain-specific reconciling buys us anything worth a constant hiss of avoidable data loss. > The same scenario applies for passwords. They very rarely change, and they > tend to change in a linear fashion. The chances that I independently change a > password to two different values while not syncing just with the right timing > is simply irrelevant. I think you're assuming that sync records contain only user-entered data, and only change when users act on them. That's at odds with the data we record to provide our user experience, which is part of the data we sync. That's what I was alluding to when I mentioned timestamps, which are eminently reconcilable and automatically change with some frequency. Perhaps a good example of user-entered data is bookmark structure. If you dump something in your toolbar on your tablet, and do *anything* to your toolbar on your desktop, you have a conflict in whatever record or records defines the toolbar structure. >> (We especially cannot do this if there's structure involved, because >> consistency spans individual records; conflict resolution requires an >> understanding of the data model. Achieving consistency is a big motivator >> for the *Sync proposals.) > > Consistency by definition cannot be achieved if you have non-zero latency and > disconnected operation. I think you and I are talking about different definitions of consistency. For the kind of consistency we care about here -- stable modification of sets of records -- you need a shared store, an atomic write primitive, the right data model, for the server to not alter the contents of content-addressable records, and for clients to retry when the atomic write fails due to a conflict. What you can't have is one client saying "folder X contains items A, B, C", and another client having just uploaded "folder X contains items A, D", and for the server's magic reconciling approach to silently orphan B and C. A client (probably the first) needs to know so that it can do something sane -- merge the items, for example. >> Furthermore, a sync implementation already needs to do client-side >> content-based data merging if it wants to support setup without blowing away >> your local data. So it's not like this is a significant additional >> requirement. > > There is no clear user stories on this for the MVP. Without such a hard > requirement a "Setting up sync with an existing account will delete all local > bookmarks. Yes/No." is a perfectly fine solution for the first shipping > version when we detect a 2nd device being linked. If it's not in the list, I suspect that's because nobody considered that scenario in drafting the MVP. It's not in any "not-MVP" list I've seen. As a user, I expect that setting up Sync on my phone doesn't delete the data on my desktop or phone, instead merging everything together in a way that makes sense. >> And at the extreme, where a data type *does* admit to a "don't bother" >> reconciling technique, that's trivial to implement on the client: a client >> downloading a server record that 'conflicts' will just apply it over their >> local record. No conflict. > > We managed to not have an acceptable sync solution for many years. If these > things were trivial, we wouldn't be at this juncture today. >From my perspective, the reasons we don't have an acceptable sync solution are >(a) we didn't rewrite Weave before it shipped in Fx4, and thus were baked into >a fundamentally limited protocol and were stuck maintaining a Labs codebase, >(b) we were never adequately resourced to build something new while still >keeping the old one from cracking (and adding features to it, and porting it >to Android!), and (c) each abortive attempt at a redesign included backward >compatibility or extensive code reuse requirements. Until it was too late. In short: we don't have an acceptable Sync solution because we were too busy working on the unacceptable one to build anything else. That's water under the bridge, but I think it's important context. Now that's we've organizationally said "let it burn and build something else", I very much want PiCL to avoid sliding down the same slope of expedient decision making, which will ultimately result in us shipping something that's more "labsy" and less "producty". That'll kill us in the long run. PiCL is our one shot at building the replacement for Sync. We should make sure it's not Weave. I understand that you're very focused on getting to market. I don't see much value in getting to market with a solution that's worse than what we have, and doesn't let us do better without another rewrite. If we do that, we'll stay DFL. I've spent the last two and a half years fielding bugs and user reports that shine very bright lights on edge case assumptions, not to mention building a brand new Sync 1.1 client from the ground up and seeing all the design flaws anew. My focus is on making sure we ship something that won't make us bleed to death from paper cuts or axe wounds. -R _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
