On 9/25/07, Mimi Yin <[EMAIL PROTECTED]> wrote: > Why did this happen? Well, unlike sharing changes, email updates do *not* > carry with them a snapshot of the item *before* it was changed. This means > that subscribers receiving Philippe's update via email have no way of > knowing that Philippe actually edited the *latest* version of the event, the > same version they have in their Chandlers. All they know is that Philippe's > email update is *different* from what they have and so to be safe, the > changes are flagged as conflicts.
Technically, Cosmo-based sharing updates don't carry along snapshots of the previous state of an item either. Let me see if I can rephrase how conflict detection works: When Chandler receives an item either from Cosmo sharing or via email and that item already exists locally, the item is examined for conflicts. The rules for this are different depending on whether you have already seen the item in the shared collection being synced or not. If you have, then we can compute what was changed both locally and remotely for the item since the last sync, and only those changes are compared. If the item has not been seen in the shared collection before (because it's either a new subscription or because someone else just added it to the collection), we have no baseline to examine to compute local and remote changes, and therefore *any* difference between the local and remote copies are marked as conflict. The same algorithm applies to edit/update (email) sharing: if you have previously sent/received the item to/from another person's email address you have a baseline to compute changes from. Otherwise all differences are considered conflicts. So it comes down to the order in which items are received. > > Now, once Philippe's Chandler *does* sync with the server and subscribers > sync as well, all should be well. The subscribers' Chandler clients should > figure out that Philippe had indeed edited the 'right' version of the event > and his changes should be applied. Currently, this doesn't work and Morgen > already has a bug logged to track this issue. > https://bugzilla.osafoundation.org/show_bug.cgi?id=10877 > > However, even if/when we fix this issue, given that auto-sync only happens > once an hour, there will still be plenty of time for users to get confused > over false-positive conflicts. > > What are ways we can ameliorate the situation? > > 1. Carefully synchronize email and sharing sync? Whenever an user sends a > shared item via email, sync it via sharing as well. Whenever an user > receives a shared item via email, sync it via sharing first. Email/Sharing are both asynchronous operations and trying to tie them together could be messy. I'm not saying we can't do this but it sure isn't appealing to me, especially as we add more ways to share items, such as peer-to-peer. > 2. Capture and send the 'last synced version' of an item when sending it out > via email so that Chandler Desktop recipients can tell if the sender/updater > edited the same version of the item they have. I don't think this is something that can be solved by only changing the way edit/update works because that would just solve the case where the item is received via sharing prior to receiving a different copy via email. If the order were reversed and the item arrived via email and then a different copy arrived via sharing, the differcences would still be in conflict. You can even get these conflicts for an item in two shared collections without involving email: if you are sharing collections A and B with me and an item is in A, but I copy it to B and make a change, then you sync only collection B, any changes I made will be in conflict on your item until you sync A (at which point the conflicts will disappear automatically). This is not a scenario people are likely to run into. So I am thinking that if I fix bug 10877 that will at least make the problem less likely to appear. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
