Re: [aerogear-dev] how about this API for sync?
On Tue, Dec 10, 2013 at 8:34 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
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.
+1
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
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Attachments:
- attachment.html (text/html — 4.6 KB)