SYNC - Collision handling

[MysticJay]

SYNC has a general design issue:
let's assume we have two clients.

Every 3 Minutes each client checks, if the file on the drive has changed (SYNC stores a UUID of the client that did the last update in the file). If so it will replace local data of the registered plugin (yes, there is no delta handling).

This is fine if you prepare your data at home and then go out to play and use IITCm (usecase).

The trouble comes, when you use both clients at the same time (within that 3 minutes window):
every time a registered plugin has changed its local data it will trigger SYNC to update the file.
SYNC will simply replace it without prior checking anything.

So if you change one element on first client, then an other element on the second client, the second change will survive.

Many agents have lived with that problem without even noticing it, so we could just ignore it...
IMHO not a good idea, now that we know the issue and the cause.

Should be easy to fix you would guess, but it is not:

• SYNC does not know about the structure of the plugin's data. UNIQUES data is pretty flat, one key per portal visited, 10.000 keys in the file. Bookmarks is hierarchical with exactly two keys on top level: MAPS and PORTALS. Below we find folder-objects and only then the entry-objects. Moving a bookmark from one folder to an other is a complex action, causing many changes. Thus the easiest is to copy the whole data.
• The different clients might not be online or not connected to drive while the user changes entries.
• A client might get killed, reloaded or simply pushed to background and nothing will sync at all.

Making a professional solution with locks, semaphores, databases, delta handling, checks et.al might be a good practice for a programmer but also create a very complex and expensive (CPU) solution.

The current proposal is:
Step 1: we are able to identify a collision, so we will ask the user "remote, local or abort?"
Step 2: the plugin can provide a collisionHandler-function. As it knows the data structure it would be up to the plugin's author to implement what ever he thinks.

The proposal will keep
SYNC easy, without the need to know anything about the data it handles (transparency).
the responsibility with the user (step 1) or
with the author of the plugin, while providing an alternative (step 2)

The change will not break any 3rd-party plugin, data or structure.

[MysticJay]

collision detection has been implemented for the following case :
Client1 and Client2 use SYNC.
Client1 starts at 12:00 and would check the drive at 12:03 for changes
Client2 starts at 12:01 and would check the drive at 12:04 for changes
Both have the same data
Client1 does a change to object A and writes it to the drive at 12:02:00
The drive has data +A
Client2 does a change to object B and writes it to the drive at 12:02:10
The drive has data +B

At 12:03:00 Client1 would check the drive and find data +B and overwrite the local data, loosing the changes done for object A.

The new routines will now STOP the syncing and launch a dialog to ask for a user decision on which set of data to be used.

As already pointed out: as SYNC is neither aware about the data nor its structure, it will not be able to merge or decide on other means how to process the data. As these situations are very rare anyway the effort to implement would not pay at all.