[Design] Updating share items results in false positive conflicts
jeffrey at osafoundation.org
Tue Oct 9 09:25:27 PDT 2007
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.
More information about the Design