Hi Mimi and Morgen, > *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. > > 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. > > Any other related scenarios? Any other options for addressing this > issue? Has anyone else noticed this behavior?
Nearly every time someone has sent an email update to an item in the Office collection, I've seen spurious conflicts, so I've definitely noticed the problem. Just for completeness, to answer "Any other options for addressing this issue", I'll cautiously mention the solution to this class of conflicts I was interested in pursuing when we discussed conflict detection a while ago, but I'll preface this with the fact that I don't really think this is a good use of our resources at this point. The idea would be to add another layer of complexity to sharing and add the concept of a sharing-version identifier to each item. I think when I last mentioned this PJE said it sounded a little like how Lotus Notes tracks different versions. The idea would be add a "shareVersion" attribute (I'm imagining this would be a UUID) and an oldShareVersions attribute to items. Every time sharing sent out a version of an item with all conflicts resolved, sharing would assign a new sharingVersion to the item and add the previous sharingVersion to the set of oldShareVersions. This would allow sharing to safely apply an inbound email update without conflict in the case where the inbound oldShareVersions matches our current shareVersion and there aren't any local changes. There are obvious potential pitfalls in this approach. Off the top of my head, I think this model wouldn't really work well with our current policy of sending non-conflicting changes to the server while we still have unresolved conflicts. And the server would need to understand this model when non-Desktop clients changed items. All in all, I don't think this plan is anything like fleshed out, and I think it would add enough additional complexity to sharing that it's kind of unappealing to put energy into right now. But in my real life use of Chandler, I've yet to see a conflict that I didn't think was spurious, so I've found our current conservative approach to marking items as conflicting a little cumbersome. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
