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

[Mimi Yin]

Jeffrey came by last week and dropped a pile of messy sharing issues  
on the floor. After chatting for an hour, we came up with some ideas  
for solutions and issues. Below is a bit of a potpourri of problems,  
so please feel free to split the thread into appropriate sub-topics.  
(Morgen snuck in with a comment before I had a chance to send it to  
the list ;o)

(Please respond to this thread on the Design list.)

> On Jul 24, 2006, at 10:14 AM, Mimi Yin wrote:
>
>> What happens when someone turns read-only items into read-write  
>> items by illegitimate means?
>> + I subscribe to a collection (Apples) on Cosmo read-only
>> + I compromise one of the items in that collection and re-share it  
>> in a different collection (Bananas), read-write.
>> - What happens?
>> - The item in question is stored twice on the server, in separate  
>> collections (Apples and Bananas), in separate user accounts. So  
>> the item that has been re-shared and is not connected on the  
>> server to the original item from the original read-only share.
>> - In my client, there will be a conflict when I sync the Apples  
>> collection. The version of the item from the Apples collection  
>> should always win.
>>
>> What happens someone legitimately gains read-write privileges to  
>> an item that they previously had read-only access to?
>> + Read-write access on the item overrides read-only access
>>
>> Ways in which to gain read-write access to an item:
>> + Subscribe to a share with a read-write ticket
>> + Receive an item via email
>>
>> Single-item URLs
>> + Always share individual items from the user's All collection on  
>> the server
>> + Users must have an account with the Hosted Service /  a Cosmo  
>> server? in order to do item sharing
>>
>> ===
>>
>> MERGING ITEMS
>> 3 scenarios:
>>
>> 1. Losing touch. Connecting back up. Resultant conflict merge
>> + A shares his contact with B. B stops sharing with A.
>> + A shares his contact with C. B and C start sharing A's contact.
>> + B and C have different versions of the contact.
>>
>> What happens?
>> + This is essentially a conflict merge and should be handled  
>> thusly. Most likely, C's version of the contact should win over B's.
>> + Ideally, we have support for private annotations and any notes B  
>> jotted down could be stored as private annotations, rather than  
>> being overwritten.
>>
>> 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)
>>
>> 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.

Morgen wrote:
> Seems like per-item ACLs is the natural fallout of items belonging to
> multiple collections...
>
> The good news is that Chandler repository already supports such per
> item ACLs.  The hard part will be to provide users a sane way to
> manage them.
>

I think we don't want to allow users to manage per-item ACLS. At least
not in the short-term. Instead we should derive what the per-item ACLs
should from other things that the user does. (e.g. subscribe to a share
with read-write access that contains items that were previously shared
with read-only access or receive an item from the sharer via email that
they already had via a read-only subscription)


:o)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060724/cace5a3e/attachment.html