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

[Summers Pittman]

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 
> <mailto: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.

>
>>
>> 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 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/b22325bd/attachment.html