Guido van Rossum, now at Dropbox, is starting a series of posts that
describe how the Dropbox data store syncs arbitrary tables of data across
clients. Of note to me is how they resolve conflicts. In short, they don’t:
If you’re familiar with the theory of Operational Transformation (OT), you
might be surprised that the server doesn’t even attempt to resolve conflicts.
We use OT-style conflict resolution on the client, but leave the server to
simply serialize requests. This allows conflict resolution to be defined by
the client — your app — giving you more freedom than traditional approaches
(which usually require that the rules for conflict resolution be fixed). As
you will see next time, a Datastore API client may customize conflict
resolution to fit its own requirements.
Quite reminiscent of git. You try to apply your batch of changes. If
Dropbox says you are not up to date with other changes, it’s your job to
replay your set of changes on top of the current state of truth. Then you try
to apply your freshly rebased batch of changes back to the server again.
General purpose syncing is hard, hard, work. This series will be useful not
just because it shows off Dropbox’s forethought, but because it shows how much
engineering is necessary to solve the really useful problems we have today.