On 7/26/13 12:09 PM, Andreas Gal wrote: > Which key approach we use is critical, however. Otherwise finding the > dupes will be difficult in the client.
I was anticipating randomly-assigned-by-the-device keys for all records. Then the code which merges downstream changes into the local datastore would pay attention to duplicates and merge as appropriate. E.g. for passwords, if we have a local (key=1,URL=foo,pw=A), and the server sends us a (key=2,URL=foo,pw=B), then the local code is responsible for deleting key=1 and letting the server's key=2 survive (with whichever password seems better, latest-timestamp or whatever). The same-object-different-key situation happens mostly during an initial merge of distinct histories that were created by the same person, for example if two browsers were kept in sync by some other tool (which didn't manage GUIDs). It can also happen when users add the same bookmark to two different devices at the same time (or when the server is down). But I think both can be handled by the merge code. Another reason for random GUIDs is that the DB keys are unencrypted. So putting a hostname or URL into the key means exposing them outside the encrypted payload, which for some datatypes would be a privacy loss. cheers, -Brian _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
