Finally got around to reading the whole thing and responding.
That’s true for this last example, but that one explicitly explains the limits of such an algorithm for automatic resolution. The other examples deal with other types of resolution. Consider this one for example:
The paper also mentions that this not meant to resolve 100% of conflicts automatically, although it’s clearly a side comment and the goal is to automate as much as possible (also leaving open the implementation of a schema language in order to account for domain-specific data structures and resolution strategies).
An implementation may keep metadataabout the provenance of each value (who made the change,on which device, at what time) to assist the developer inautomatically resolving such conflicts in an application-specific way, or deferring to users for manual resolution.
That said, I do agree with the following statement:
But I disagree that having a “proper database” on the remote end is solving this in a way that keeps the idea of remoteStorage being a simple key/value store and would likely put us on a path towards considerably more complex server specs and implementations at some point.
Having some kind of optional ORM on the client-side however – in addition to simple object operations – makes a lot of sense to me, and adding APIs for resolving conflicts to that seems to naturally make sense as well then.[quote=“untitaker, post:2, topic:354”]
Since remoteStorage.js now knows so much about the data it stores, it can now show a simple dialog that shows the conflicting task items side by side and ask the user to pick one. This doesn’t necessarily look pretty since it will also show a lot of internal information (such as the table row’s ID).
[/quote]
I can imagine this as being an add-on for the (new) widget, with some kind of simple API to pass the conflict data as well as a schema and/or fields to be hidden for example. In addition to that, it should be easy to do it with existing UI libs, of course.