[Cosmo-dev] [Cosmo][Scooby]Sharing URLs/Rationalizing UUIDs
mimi at osafoundation.org
Mon Jul 24 14:09:26 PDT 2006
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.
>> + 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
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cosmo-dev