Richard Newman wrote:
Come on, give me some credit. I wasn't addressing that single straw example.
You brought up the "two devices both increment a usage count" example. I simply
asked you why that argument is relevant. Anyway, it seems that we at this point agree
that its irrelevant whether the count is maintained precisely, or merely approximately,
which I said a little earlier. Progress!
You're asserting that we can always discard one of two conflicting records on
the server without meaningful impact to a user -- server-side blind conflict
resolution. A write on a client gets seamlessly undone at a later date during
replication.
I assert that we can't always do so; you'll see bookmark renames reverting,
passwords changing to the old value, and so on, just because of timing
accidents.
Lets go through your concrete examples. Lets start with bookmarks. How
often do users rename bookmarks? We can probably get some data on this.
Until then I will go with my own experience, which is probably at least
in the ballpark representative. I rename bookmarks on average ...
actually closer to never, but just to humor you, lets say "every few
weeks". Thats probably a gross overestimation of the frequency, but lets
roll with it. A timing accident here would mean that on one device I
rename a bookmark, then don't sync for many weeks, while concurrently on
a second device I decide to rename the bookmark independently to a
different value, and then sync, and then finally sync my other device,
and lose the information. I would claim that this scenario happened in
the history of humanity syncing devices near 0 times.
Anyway, even if you were right and this is a relevant scenario, which I
am pretty sure you are not, you are forgetting that these are not
independent data sources. In both cases its the same person doing the
renaming. Even if I rename a bookmark twice on two independent devices
and convenient for a few weeks don't sync and then sync in just the
right/wrong order, and on top of that I rename the two bookmarks to
different names, even in this astronomically unlikely case, I am
actually very likely to rename in both cases to something with the same
meaning (maybe I misspelled one of them?), in which case for all intents
and purposes it doesn't matter which one we pick.
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. We can run the
math on this with real data, but I bet you that the failure scenarios
"user dies of heart attack" and "user gets hit by meteor" both rank
higher than the probability of your scenarios.
The result of that runs the gamut of user opinion from "unnoticeable" through "Firefox feels
kinda unreliable" to "Firefox lost my password". We can do much better.
We can always do better. Thats not the point. Engineering is all about
making the right trade-offs and getting to market. Firefox has thousands
of known bugs, and probably hundreds of thousands of unknown ones. Yet,
it works just fine for many use cases and many users. Your line of
argument reminds me a bit of claiming that 32-bit numbers are not
sufficient for the usage count, because that might overflow. Technically
you are right. In practice, you are wrong.
(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. If thats the motivation here, we
will be spending many more years researching an insolvable problem.
Fortunately, that is not the motivation here. The motivation is to solve
the user stories we went over in the meeting, and to get to market
quickly. Please read through the goals again that we all agreed on.
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. We can
improve from there. Please note that linking one mobile device to one
desktop device doesn't cause a conflict because all bookmarks go into a
separate Mobile root folder. Only a 2nd mobile device that is being set
up after extensive use and bookmarking would cause a conflict. I content
that this scenario is sufficiently rare to not matter for an initial
version.
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. Lets
get the MVP done, landed, and turned on by default. After that I am very
happy to entertain a more complex and fancy conflict resolution
approach. Iterate! Until then all eyes should be on the ball: make us no
longer be DFL.
I agree that _needless_ complexity is our enemy. But we should be aware of the
consequences of apparently easy simplifications.
I am happy to entertain any concrete examples where we should add more
complexity, but please list actually valid and realistic use/conflict cases
Thanks,
Andreas
-R
----- Original Message -----
From: "Andreas Gal"<[email protected]>
To: "Richard Newman"<[email protected]>
Cc: "Lloyd Hilaiel"<[email protected]>, [email protected]
Sent: Friday, July 26, 2013 5:49:20 PM
Subject: Re: whats the key anyway?
Help me understand for what use case a precise count is relevant.
Andreas
Sent from Mobile.
On Jul 26, 2013, at 17:39, Richard Newman<[email protected]> wrote:
I disagree: repeating the mistakes of Weave is the biggest enemy here. And one of those
mistakes was thinking that "good enough" was good enough, when it manifestly
was not, at any level of abstraction. We should not be trading the very basics of
correctness for the possibility of a closer ship date.
----- Original Message -----
From: "Andreas Gal"<[email protected]>
To: "Richard Newman"<[email protected]>
Cc: "Lloyd Hilaiel"<[email protected]>, [email protected]
Sent: Friday, July 26, 2013 5:29:48 PM
Subject: Re: whats the key anyway?
There are many different ways to do this. And it simply doesn't matter
which one we chose. Losing a usage count is irrelevant. As long we are
reasonably counting, that's perfectly fine. Complexity is our biggest
enemy here. Precision is not a design goal. Fast delivery of a
solution that reasonably approximates consistency is.
Andreas
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
