[aerogear-dev] how about this API for sync?

[Sebastien Blanc]

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

>
> On 9 Dec,2013, at 17:06 , Summers Pittman <supittma at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131210/24da459a/attachment.html