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