Hi Folks, This email sharing stuff is kind of a tangle of responsibility and interest, Mimi/PPD are obviously interested in user experience, PJE and Morgen are working on transport/protocol issues, Morgen's sharing work is potentially affected, Brian Kirsch is in charge of email, Grant's responsible for domain model changes this will require, and Grant and I have been working on lubricating discussions in pursuit of a good translation of PPD's goals into an engineering picture.
The ideas I had about using a per-item sequence and dtstamp didn't, upon deep consideration, seem worthwhile, so folks have been heading in a different direction (thus, feel free to not give any weight to implementation ideas from this http://lists.osafoundation.org/pipermail/chandler-dev/2006-December/thread.html thread, although the caveats therein about there being no perfect solution until we add more sophisticated versioning or locking still apply). The other day on IRC several of us had a good conversation about what we should be passing around when sending emails around. A before and after version, or some riff on a diff of the item and its previous version, seems like the way to go. There's still a lot more to the picture than what goes over the wire. Today Grant and Mimi and I talked more. What follows is a rough sketch of a way to approach the managing of items being shared around by email. I imagine Mimi will have an alternate, user-experience focused, summary. Our discussion today focused a lot on the concept of a message-id. In the standard email universe, every email should have a unique message-id. When sharing emails that are changing, it seems to make sense to change the email's message-id (while leaving the item UUID the same), because it's really a different message. These message-ids have no order, they're just unique identifiers. But they could be used to give a reasonably coherent picture of which updates have applied to items. So, to start with, just before an addressed item is changed by sharing (because it's being emailed out, or a new version is put up on a server), we should do three things: A) Add the existing messageId to a messageIdReferences attribute on the item B) Assign a new, random messageId C) Track some attribute on the item pointing to the current repository version (I think something like this is being done by sharing now, to make sharing of individual items work, it'll need to happen on a per-item basis, not per share, which is hopefully not a big change from what we do now) The messageIdReferences attribute is important because it will shape how email updates are handled. If an email update's messageId is in a local item's messageIdReferences, this implies someone, somewhere has already merged in that update, so the update should be ignored. Similarly, if an update's messageIdReferences contains the local item's current messageId, we should follow the "server wins" strategy for the update, except the server here is email. So, specifically, all attribute values in the update should be applied to the local version, except for attributes that were unchanged in the update and which have been changed locally after the last messageId change. The theory here is that the chain of composers of the update are known to have seen the local version at some point, so the update should be treated as more recent and thus authoritative. Lastly, if neither the local messageId nor the update's messageId is in their opposite's messageIdReference, any non-conflicting changes (attribute changes whose "from" value matches the local attribute) should be merged in, other's should be discarded, i.e. "local edits win", which seems like a fine choice in this case because the user will still have the email update available to compare to the Chandler item. That implies that we should serialize some marginally human readable version of the important attributes in the email update. As a "local edits win" change is processed, a new messageId should be created, and messageIdReferences should contain the union of all previous messageIdReferences plus the update's messageId and the previous local messageId. Finally, if any attributes conflicted, a conflict message should be added to the item alerting the local user of that fact (how we render such messages is a separate issue, but I'm sure we can do something simple with this to start with). When the server sharing layer processes addressed items, it should take the union of messageIdReference attributes, rather than having one override the other. Beyond this, server sharing could behave exactly as it does now (server wins), or we could potentially add some awareness of messageIdReferences and throw away server changes if their messageId is contained in the local item's messageIdReferences. Oh, and one other small detail, if a server or email update merge changes into an item, the local lastModifiedBy should win. Does that make sense? Does it seem like a good approach? Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
