Quick follow-up: > On Jan 30, 2018, at 19:00, Kit Cambridge <[email protected]> wrote: > > 2. Voluntary restore. As with (1), this resets the sync ID and the last sync > time, and sets `syncChangeCounter = 1` and `syncStatus = NEW` for all > restored bookmarks. Unlike (1), this also wipes the server and all clients > before uploading the local tree. The effect is that receiving devices > *follow*, not merge: they erase everything in Places and replace their local > trees with the restored tree on the server.
I conflated the behavior of the sending and receiving devices here. For folks following along, the sender sets `syncChangeCounter = 1` and `syncStatus = NEW` for all restored bookmarks, wipes the server, and sends a `wipeEngine` command to all other devices. The receivers handle the `wipeEngine` command, then reset *their* sync flags...which, since we just cleared out Places, only sets `syncChangeCounter = 1` and `syncStatus = NEW` for the roots. This code path is identical to (1); that's what I mean by "a follow is a special case of a merge with no local tree." > > * `PREVIOUSLY_SYNCED` items are functionally identical to `NEW` (for > instance, deleting a `PREVIOUSLY_SYNCED` item does not write a `NEW` > tombstone for it), except they use your approach for reconciliation. `PREVIOUSLY_SYNCED` should probably disqualify records from deduping (like `UNKNOWN`), or we’ll ignore tombstones for reuploaded items with content matches. On a somewhat related note, I’m considering splitting up `UNKNOWN` into `RESTORED` (case 3 in this email) and `RECOVERED` (case 2), because we want to handle trees containing bookmarks with those statuses differently [1]. For items, we’d have five statuses: * `RESTORED`: Don’t dedupe, don’t write tombstones, use normal reconciliation logic. If we have any of these in Places, reset the sync ID locally and on the server, send a wipe command to all clients, and start over. * `RECOVERED`: Don’t dedupe, don’t write tombstones, use normal reconciliation logic. If we have any of these in Places, set `needsMerge = 1` for all items in the mirror, and run a full merge. * `NEW`: Dedupe, don’t write tombstones, use normal reconciliation logic. No other special behavior. * `NORMAL`: Don’t dedupe, write tombstones, use normal reconciliation logic. * `PREVIOUSLY_SYNCED`: Don’t dedupe, don’t write tombstones, use special reconciliation logic that always prefers deletions. For tombstones, we’d have three; `RESTORED` and `RECOVERED` aren’t meaningful. * `NEW`: Local deletions that haven’t been uploaded to the server yet; use normal reconciliation logic. * `NORMAL`: Stored deletions. Also use normal reconciliation logic, so the item can be resurrected. * `PREVIOUSLY_SYNCED`: Use special logic that always prefers the deletion. But maybe this is getting unnecessarily complex? Cheers, - kit [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1199077#c5 _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
