On Tue, Dec 10, 2013 at 8:34 AM, Erik Jan de Wit <edewit@redhat.com> wrote:

On 9 Dec,2013, at 17:06 , Summers Pittman <supittma@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.

Yes, let's keep it simple for now. So, here in this situation the server just report the conflict, right ? He does not take action on the conflict itself. Do we state here that the client will always be responsible in† resolving the conflict ?
In your first message, you define a ConflictHandler interface, do we also want to provide some implementations of the ConflictHandler that covers most of the use cases ?†

As examples:
Legacy Servers can be periodic pollers.
Minor changes can be a sync on push type thing.
And realtime, is well, real time.

aerogear-dev mailing list