Slow sync not supported?

[GoogleCodeExporter]

The webpage and wiki claim that slow sync is supported, but it seems this isn't 
really the case? The following happened for me:

 1. A syncml connection was established.
 2. The client did an Alert with code 200, requesting a normal sync.
 3. The server did an alert with code 201, requesting slow sync (I think because of some anchor mismatch).
 4. The client sends all of its contacts using "Add" commands.
 5. The server duplicates all of the contacts.

This is not how a slow sync is supposed to work, I think? I'm not 100% sure, 
because the SyncML protocol specification seems to only specify how to start a 
slow sync, not how it actually works.

The duplicate items are also linked to the same client_item_id in the mooha_map 
table, which also shouldn't happen, I think. Looking at the _clientSync 
function, which should be handling the slow sync case, I can't find any code 
that actually handles this.

What's up with this?

Original issue reported on code.google.com by matthijskooijman@gmail.com on 6 Sep 2010 at 3:07

[GoogleCodeExporter]

Looking a bit more closely, it seems that slow sync is partly supported: When a 
slow sync is initiated, the server anchor is reset to 0, causing _serverSync to 
send all of the items to the client (as expected). So it seems only _clientSync 
should be improved to support slow sync.

To prevent a complete mess with duplicate entries, one could change the "Add" 
handling in _clientSync to check the mooha_map table. If the item is already 
present in the database, it could somehow handle this specially to prevent 
duplicates. I'm not sure how to handle this exactly, though. Options seem to be:
 1. Just pretend this was a Replace action and use the client value.
 2. Ignore the command and keep the server value.
 3. Do something smart with comparison and merging (though it's quite hard to do this right, I guess).
 4. Look at the timestamp inside the vcard and use the newest.

Number 3 is probably best, but I wouldn't know how that would work. That leaves 
4 as the runner up, which is probably sufficient. All four options are better 
than the current solution that duplications the entire address book (there is a 
point to duplicating data instead of risking losing data, of course,  but 
manually having to remove half of your address book doesn't work). I did just 
realize another option:

 5. Compare the entries and only apply duplication when they are different. The tricky part here is that there might be small differences in notation etc., some fields being unsupported on some devices, etc., so this is probably quite tricky as well.

Original comment by matthijskooijman@gmail.com on 6 Sep 2010 at 6:47

[GoogleCodeExporter]

After some unexpected behaviour, I've found out that when a slow sync happens, 
_all_ server anchors on a given database get reset (i.e., for all clients). 
This makes sure that all data gets resent to all clients, not just the one 
doing a slow sync. I'm not sure if this is a bug or a feature, but it was 
unexpected to me.

Original comment by matthijskooijman@gmail.com on 6 Sep 2010 at 7:26