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

[Sebastien Blanc]

On Tue, Dec 10, 2013 at 4:13 PM, Summers Pittman <supittma at redhat.com>wrote:

>  On 12/10/2013 02:34 AM, Erik Jan de Wit 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.
>
> This technique is good for synced text.  We've hooked our horse to the
> JSON cart pretty hard so we should be able to deal with that for a large
> number of cases.
>
>  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 Pipes aren't data per se.  They are a one way query mechanism (IE the
> pipe doesn't start spewing data all over your living room floor for no
> reason.)  Pipes can be used by Sync to fetch data once a signal to refresh
> has been received however.
>
>  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.
>
> 'Toiotas' Yes, 'Toiotas' (no cap) no.  That would actually be correct in
> patch diff merge.
>
What's the difference between these 2 ?
Bu the point of Erik was that we don't want this kind of merge, no ?

>
>
>
>
> 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.
>
> We can limit legacy servers to read only data (from a client perspective).
>
>  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.
>
>
> Of course, offline is just laggy sync.
>
> But lets take two separate but similar legacy use cases.  Downloading the
> weather forecast based on your location and synchronizing a todo list.
>
> The weather data probably won't change during the day.  So every night at
> midnight + jitter our sync can download the forecast from a restful URL and
> be done.  There is no conflict because the client data can not / will not
> change.  This is a very simple case to implement.
>
> Syncing a Todo list is more complicated  because it can change from
> multiple clients.  HOWEVER the application has a restriction that todo list
> items may only be added and removed but not reordered or edited.
>
> The flow for that could look like
>
> 1. User 1 on Android creates a TODO list.
> 2. Android app creates TODO list copy on server.
> 3. Android app registers a sync with the server for the todo list
> 4. User 1 adds item to TODO list.
> 5. Server syncs its list with Users list.  returns OK.
> 6. User 1 access his list in web app.
> 7. Web App registers a sync on the server with the todo list.
> 8. User 1 Edits his list.
> 9. Web App applies edits and sends deltas to Android app.
> 10. repeate ad nausiem.
>
> In this case conflicts can only happen if a user deletes the same item (no
> practical conflict).  So a conflict resolver will be trivial.
>
>
>  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.
>
> Yeah.  The more I poke and play with things the less certain I am that
> adding it to the pipe is a good idea.  I think we need something separate.
>
>
>
> 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 listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> 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/148bdec7/attachment-0001.html