[Design] [Cosmo][Scooby]Sharing URLs/Rationalizing
mimi at osafoundation.org
Tue Aug 1 14:57:19 PDT 2006
Process question. All of these things will eventually need to be a
spec. Is this something Morgen / Sheila and I should work on
together? Track proposals...document designs.
On Jul 31, 2006, at 4:36 PM, Jeffrey Harris wrote:
> 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
> or PinkFlamingo's EmailAddress (probably creating a stub item with
> 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
> 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.
This would certainly be the ideal solution. What's a good way to
phase this? Store the UUID for now...but defer the reconciliation
functionality until later.
>> *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
> I think when we do an export, we might consider copying (i.e.,
> 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
> any changes they've made) into the original item, but they don't
> have to.
Oooh, nice. I was thinking that it was really on the re-import end
where you want to make this kind of decision.
> In this architecture, we could have a special restore-from-export
> that would get back the original UUIDs, we wouldn't need backup and
> export actions.
How realistic is this in Beta? Sorry to be a broken record.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design