This will be put in the final conflict resolution document and linked once complete.

Conflict resolution can be performed on the client by using the current conflict resolution method but by also introducing a third state. This third state can be used to perform a much more comprehensive merge which can also satisfy the requirement of field level only conflicts.

Solution 1:

Client sends base with every request. Drawbacks:

a - Large increase in network requests for potentially little gain
b - Potentially wasteful as we are sending base to the server with every request in anticipation of a request

Solution 2:

Client calculates the base when there is a conflict error returned from the server. This version involves a low overhead and would mean a 3 way merge can be easily calculated. Drawbacks here include the fact that the base could have moved forward since the original operation fired. An example is when subsequent offline mutations are fired. The base moves with the second mutation and the client no longer has access to the correct base for its mutation.

Solution 3:

Client calculates the base for every mutation, but takes a lightweight approach to using this base. When offline, the operation will proceed as usual but the base will be persisted to the offline queue with the operation. If a conflict occurs, we will then have access to the correct base - with the added advantage that the base also persists across restarts.

When online, the base is calculated and stored in memory. In this scenario if there is a conflict we still have access to the record from the in memory cache.

Currently prototyping solution 3 with a demonstration to stake holders to follow.