On 12/17/07, Randy Letness <[EMAIL PROTECTED]> wrote: > Mimi Yin wrote: > > Aparna and Andre have been investigating a bug where Andre gained > > read-write access to a Chandler item he received via email by adding > > it to a second shared collection he has read-write access to. > > > > As a result, Aparna and I were seeing Andre's non-emailed edits on the > > item and vice versa, even though we never set up a formal sharing > > relationship by exchanging read-write ticket URLs for a commonly > > shared collection. > > > > Randy, Morgen, could you give us on the design list an update on where > > you are wrt this issue (or point us to the latest dev-list write-up)? > > Ah yes my favorite topic. I've started a page with some notes: > > http://chandlerproject.org/Journal/CosmoAccessControlNotes > > There hasn't been much discussion on the cosmo-dev list so far (probably > because people go crazy after reading the notes). Morgen and I talked > about ideas today (I've updated the notes page with thoughts at the > bottom) and both of us are leaning towards storing copies of items on > the server (one item per account) rather than a single item (the way it > is now). This is actually going back to the way the server *used* to > work. The only problem with this is that it presents some problems > with the web ui when an item in multiple collections is updated (mainly > that the webui doesn't support this and will only update a single > collection). > > Also, the client bug for this is: > > https://bugzilla.osafoundation.org/show_bug.cgi?id=11013 > > I don't think there is a server bug opened yet. > > -Randy >
[Not sure if this is a "design" discussion, or one for the "cosmo" list, but I'll reply here...] As Randy noted (on http://chandlerproject.org/Journal/CosmoAccessControlNotes ), there are quite a few advantages to going back to compartmentalized collections, where if an item is in multiple collections, each collection maintains its own copy of the item. (Instead of typing compartmentalization over and over, I will refer to this as "c18n" from now on.) - With c18n, If someone gets a hold of one of your item's UUID (through email or some other means), they can't modify your copy of it unless they also have write access to a collection that you are syncing. And if they *do* try to slip a change through some other collection you're syncing, Chandler's conflict management will flag it as a pending change for you to approve/decline. - Today, without c18n, if someone has one of your UUIDs, they could publish it to the server before you get a chance to, thereby preventing you from publishing your own item! - With c18n we could provide users with a way to replicate their collections among their own multiple clients, keeping "read/unread" in sync, etc. By publishing a second copy of a collection to the hub, Chandler could include all the "private" attributes that you wouldn't want to share with others, but which you *do* want to share with yourself across multiple Chandlers. - Without c18n we moved away from deterministically generating an item's UUID from its icalUID, because when multiple users import a public .ics file from somewhere and then publish the calendar to the Hub we want the items to be distinct. I believe this is leading to having multiple UUIDs with the same icalUID as Jared is seeing on the Hub. With c18n, we can go back to generating UUIDs based on icalUID, solving this problem, while still allowing people to publish the same .ics-imported public calendar to the Hub. ~morgen _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
