11:58 a.m.
On 12/10/2013 11:39 AM, Erik Jan de Wit wrote:
>> 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.
Yes, synced text and yes JSON, is text as well, but it does not make sense to merge JSON
because merging this data will always be wrong! I’ll use the car example one more time:
one user wants to change from Toyotas to Toyota and another user wants to change from
Toyotas to Toiotas when a system merges those changes to Toiota it (the system) made up
it’s own change and really nobody wanted that to happen.
Hi,
diff merge patch covers your example without generating a conflict.
https://neil.fraser.name/software/diff_match_patch/svn/trunk/demos/demo_p...
If I would write a book and changed a paragraph and somebody else was writing a paragraph
in the same book merging those would make sense.
>> 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 you see no use case to make Pipes able to sync, because I think it would be a nice
addition
I don't feel like Pipes are the thing that does syncing.
Does HTTP sync? Does SQL sync? The answer to both cases are no. But an
applicaiton can use both HTTP and SQL to do what we are thinking of when
we say sync.
>> 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).
So my idea of sync is to be able to work offline and then sync the data back to the
server when I’m online again. Just getting data from a server periodically is not really
what I had in mind for syncing, I think that it doesn’t need an API, one can just fetch
data again in an OnlineEvent.
It is still a valid use case for online support and
there is a TON of
work around just that with mobile.
1) adding a jitter to when you sync so the server doesn't get every user
hitting it at the exact same time
2) retry and exponential backoff
3) notifying the external system of data changes
4) Managing and batching sync operations so that we don't kill the battery.
Just because I want to start with a simple use case doesn't mean you can
dismiss the use case.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev