On 12/18/07, Philippe Bossut <[EMAIL PROTECTED]> wrote: > > > Morgen Sågen wrote: > > 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. > > > 2 problems I see with the c18n proposal: > - item sharing between collections in the webUI won't work: so Chandler > Server is basically siloed, not per kind of items but per collection.
If there us any chance the Web UI could update each copy of the item that a change applies to, like Chandler does, then although the server would be internally siloed, the user would never know it. > Debatable if its against the Chandler philosophy or not. I'll leave that > issue open. Let's put it this way, we're running out of time to do something about this, and if done right, the user wouldn't need to know there are multiple copies of items on the server. > - Adding a 3rd Chandler client in the mix still allows propagation > scenarios where an edit is done when it shouldn't. e.g.: > - User 1 publishes collection A with item aaa > - User 1 gives read-only ticket to User 2 and read-write ticket to > User 3 > - User 2 gets item aaa, modifies it and shares it in published > collection B > - User 2 gives read-only ticket to User 3 on collection B > - User 3 syncs all: he gets edits from User 2 on item aaa from > collection B, those edits get propagated to collection A In this scenario, any differences between collection A's aaa item and collection B's would show up as conflicts for User 3 (since 3 is receiving the same items from two different shares) and no changes would be automatically propagated. Instead, if User 2 had not made any changes, and simply added aaa to collection B, User 3 would *not* see any conflicts; User 2 could then later on make changes that *would* automatically propagate. To prevent this I propose that if Chandler syncs a collection and receives an item that it already has a copy of elsewhere, the user is asked whether or not to allow changes arriving from the collection. We already have "pending removals" in the conflict dialog, and we would now be adding "pending additions". If they decline, then from their standpoint, the item is not a member of that collection at all. If they approve, the item will appear in the collection and inbound changes will be applied normally. In the above scenario, User 3 would make that choice. ~morgen _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
