[Design] [Cosmo][Scooby]Sharing URLs/Rationalizing UUIDs treatment/ACLs/Export

[Mimi Yin]

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  
> 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.

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  
>> 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.

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  
> option
> 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.

>
> Sincerely,
> Jeffrey
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design