3 ms·

I've had to build sync systems in the past for RoR + iPhone and was amazed that there was no industry standard approach to sync. Even syncing contacts on my iPh

by arrel 16y ago

I've had to build sync systems in the past for RoR + iPhone and was amazed that there was no industry standard approach to sync. Even syncing contacts on my iPhone still goes haywire regularly. Is it just one of those "hard problems" that's still searching for a solution, or is there a tried and true online/offline sync algorithm that works?

aaronblohowiak 16y ago
There are three approaches to sync, and all have their pros and cons. The complexity in sync comes from conflicts, and the three approaches vary in how they handle conflicts, with varying implications for the end user. Rule-based resolution, Locking, Merge Rule based is something like last person wins, always accept this actor's changes, or pick the variation based on some simple criteria. This is easy to implement but it causes loss of (potentially unrelated) changes that one person made. Locking (pessimistic and optimistic) tries to make the above better because it either prevents divergence or prevents changes from being lost by returning an error (refusing to commit the conflict-inducing change to one of the data stores.) Merge is the hardest of all, and it is a series of trade-offs and compromises. From diff-match-patch to three way merge to operational transformation, vector clocks and so on, there are many ways to try and handle merging that all have their own ups and downs. (google the iterating bigrams in that sentence for more info.). You ultimately need to get your own application logic in the merge process -- for instance, "we want to disallow changes to the title After the PDF has been sent" is a business rule, but then your remote client had changed the title while disconnected and somebody else sent the PDF. There is no simple algo that will handle text merging, state machine guards, and varying merge strategies. Finally, different merge strategies have different amounts of data transfer required to perform the synch negotiation.

by arrel 16y ago

aaronblohowiak 16y ago

There are three approaches to sync, and all have their pros and cons. The complexity in sync comes from conflicts, and the three approaches vary in how they handle conflicts, with varying implications for the end user. Rule-based resolution, Locking, Merge Rule based is something like last person wins, always accept this actor's changes, or pick the variation based on some simple criteria. This is easy to implement but it causes loss of (potentially unrelated) changes that one person made. Locking (pessimistic and optimistic) tries to make the above better because it either prevents divergence or prevents changes from being lost by returning an error (refusing to commit the conflict-inducing change to one of the data stores.) Merge is the hardest of all, and it is a series of trade-offs and compromises. From diff-match-patch to three way merge to operational transformation, vector clocks and so on, there are many ways to try and handle merging that all have their own ups and downs. (google the iterating bigrams in that sentence for more info.). You ultimately need to get your own application logic in the merge process -- for instance, "we want to disallow changes to the title After the PDF has been sent" is a business rule, but then your remote client had changed the title while disconnected and somebody else sent the PDF. There is no simple algo that will handle text merging, state machine guards, and varying merge strategies. Finally, different merge strategies have different amounts of data transfer required to perform the synch negotiation.