Hi Mimi,
> *MERGING ITEMS* > *3 scenarios:* [snip] > *2. Rationalizing items shared as 2ndary items with pre-existing > versions of the same item* > + A shares an event with B. The To: field in the event points to a > 2ndary contact item for C (e.g. To: C) which contains C's First Name > and Last Name and C's email address. > + B already has a contact item for C. We want to reconcile A's > contact item for C and B's contact item for C. > + However, A didn't intentionally share C's contact item with B. So A > wouldn't want / expect B to make any edits to A's contact item for C. > > + This 2ndary contact item should be shared read-only > + This 2ndary contact item needs to be rationalized / connected with > B's contact item for C > > Why can't we share C's email address just as a string? Why does it > need to be an item at all? > + Because, B is going to want to know all of the items that are > related to C, regardless of whether those items point to B's contact > for C; or somebody else's (e.g. A's) contact item for C. > + We also want to be able to reconcile B's contact for C and A's > contact for C at some later date, incase A and B decide to one day > share a contact item for C. > > QUESTIONS > + Can we relate A's 2ndary contact item for C with B's original > contact item for C, such that both are part of an uber-contact item > that 'contains' or 'points back to' the 2 contact items for C? > + Can we share secondary items as read-only, even if the primary item > is shared read-write? > + Can B 'annotate' A's 2ndary contact item for C (e.g. designate an > email address from A's 2ndary contact item for C as the default email > address to use when sending email to C) How does this sound: EmailAddress is a separate item from a contact. When I share an event with you, I let you know the UUIDs for any EmailAddresses in the to: field. In this case lets say the EmailAddress is for PinkFlamingo, a contact you already have. When you receive the item, your Chandler would note the UUID my EmailAddress used in your version of PinkFlamingo or PinkFlamingo's EmailAddress (probably creating a stub item with that UUID). If later I share my version of PinkFlamingo with you, the fact that a stub item with the same UUID already exists would trigger merge UI. You would have the opportunity to merge your existing PinkFlamingo with mine, possibly keeping some of your original attributes as private annotations that you don't share back to me. You also store a history of the fact that these PinkFlamingos (both the Contact items and the EmailAddress items) have been merged, so if you were sharing PinkFlamingo with someone else and you share the new version with them, they'd get their own independent chance to merge PinkFlamingos. If you chose not to merge PinkFlamingos, we could provide alternate behavior where you would maintain a (perhaps private) link between the two, and designate which contact should be used by default when lists of contacts are constructed. > *3. Rationalizing import items with versions of the same items > received via Sharing* > + A exports a collection and emails the collection to B > + B imports the collection at which point, B can start to make > changes to items in the collection > + A then decides to share the collection with B > What happens? > > + When A exported the collection and emailed it to B, what was the > motivation / expectation? > - Most likely, it was not: Keep my collection and B's version of the > collection in sync > - More likely, it was: I'm making a copy of my collection for B, now > B can do whatever they want with it > + As a result, export, should really be: Export a copy > > Q. Is this going to screw up scenarios where A is exporting items in > order to back them up for himself? What if A loses part of his > repository and then decides to re-import the back-up and ends up with > a bunch of dupes? > > + Maybe we need both Export and Export copy; OR Backup and Export copy. I think when we do an export, we might consider copying (i.e., creating new UUIDs for our items), but maintaining back-links to the original items in the copy. So if the recipient of the copy ever comes across the original in sharing, they have the option of merging their copy (and any changes they've made) into the original item, but they don't have to. In this architecture, we could have a special restore-from-export option that would get back the original UUIDs, we wouldn't need backup and export actions. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
