Viability

[avin-kavish]

Based on what I read on the website, it sounds like there are some practical limitations to this. Say for example, in a collaborative document that is being edited offline, a user moves one object to one place and the other moves the object to a different place. It maybe so that algorithms can resolve and build a merged a version of the document, but who is to say whether the change by one user is correct over the other. One object can't be in two places, so I think the users have to ultimately discuss and decided which version to keep, so it's better if the document is kept strongly consistent in the first place.

[ept]

You're welcome to use strong consistency if you want, but then your app will be slow because it requires a network round-trip for every update, and it won't work if the user is offline. If you want to be faster/work offline, you have no choice but to allow different users to update concurrently. In your example, an object could be in "two places at the same time" if you use a multi-value register (see section 3.2.2 of this document); this allows you to detect that multiple users changed the position independently, and enables you to build a user interface to resolve the conflict manually. Of course, if it's too much work for the user to resolve the conflict manually, you can also pick one of the values arbitrarily, perhaps based on some application-specific rule.

[avin-kavish]

Regarding the network round-trip, I'm optimistically updating the state before each network call and reverting if the update fails. So there's no visible lag really. But yeah, I have to think about whether users would want to edit a collaborative workspace offline and synchronize afterwards. I think that's very application specific. miro.com for example, locks you out of the editing controls if you are not connected to their websocket.

[ept]

If you're making an optimistic update and reverting if the update fails, what happens if two users simultaneously make an optimistic update to the same object? Presumably the server will arbitrarily pick one of them as the winner (perhaps the one that reached the server first, or the one that reached the server last) and send the winning value to all users. The end result is exactly what you criticised, namely an algorithm that picks one of the two updates based on some arbitrary criterion.