The difference is we have different opinions, use cases, and ideas of "correct". Our users will also have said ideas so our solution should make it possible for both to be supported (even if we only provide one).
On Tue, Dec 10, 2013 at 4:13 PM, Summers Pittman <supittma@redhat.com> wrote:
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.On 12/10/2013 02:34 AM, Erik Jan de Wit 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.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.We could support documents of course, but I was thinking more about Pipes and syncing those when one has been offline for a while.'Toiotas' Yes, 'Toiotas' (no cap) no. That would actually be correct in patch diff merge.
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.What's the difference between these 2 ?
Bu the point of Erik was that we don't want this kind of merge, no ?
We can limit legacy servers to read only data (from a client perspective).
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.Of course, offline is just laggy sync.
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.
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.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.
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.
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________ aerogear-dev mailing list aerogear-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev