Re: Re: Accidentally sharing item that was only emailed around...

Morgen S=E5gen 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.
>  =20
2 problems I see with the c18n proposal:
- item sharing between collections in the webUI won't work: so Chandler=20
Server is basically siloed, not per kind of items but per collection.=20
Debatable if its against the Chandler philosophy or not. I'll leave that=20
issue open.
- Adding a 3rd Chandler client in the mix still allows propagation=20
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=20
User 3
    - User 2 gets item aaa, modifies it and shares it in published=20
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=20
collection B, those edits get propagated to collection A

Fundamentally, the fact that Chandler Desktop has this notion of=20
"platonic" items (i.e. ideally perfect UUID unique in the whole=20
universe) *and* allows read-only items to be edited will create (after=20
some sync propagation accrobatics...) conflicts.

I toyed with the idea of enforcing read-onlyness strictly on the Desktop=20
client but that creates a bunch of issues (as: how to allow the Desktop=20
user to still triage or put alarms on the items independently of the=20
server, etc...).

So I don't have a better solution but thought I'd mention the problem I=20
see here.

Cheers,
- Philippe

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design