On 9 Dec,2013, at 17:06 , Summers Pittman <supittma(a)redhat.com> wrote:
For real time sync this is a great primer:
https://neil.fraser.name/writing/sync/. The concepts can be expanded beyond text of
course.
That is a great article, but all these techniques are only cool for documents. We could
support documents of course, but I was thinking more about Pipes and syncing those when
one has been offline for a while. So for example when you have a Car that has make Toyota
and one changes it to Toiota and another changes it Toyotas merging these to changes to
Toiotas is always wrong. We don’t need merge support we only need conflict resolution.
I guess my question is do we want a really low level but universal protocol which
requires server support, or several separate APIs which can handle legacy servers, servers
with minor changes, or real time capable servers?
Cool idea to connect a legacy backend and let the front-end deal with the sync. But we
can’t support conflict resolution in this scenario. For example client1 and client2 change
the same car object. Client1 changes the property colour from red to green and client2
changes it from red to blue. The change of client1 takes place first then the change of
client2 will be a conflict. Now to detect that conflict we could fetch the entity again
and check if the colour is still the same as our original value, but it could change in
the mean time again. So there is no guarantee that the data will be consistent.
Of course we could periodically fetch data from a legacy server and merge that with the
client state, but I don’t think that this is super useful the power of sync is changing
things to be able to work offline. So I think we need a protocol, can be really simple
just versioned JSON, and a server that will compare the changes and return conflicts.
As examples:
Legacy Servers can be periodic pollers.
Minor changes can be a sync on push type thing.
And realtime, is well, real time.