Philippe Bossut wrote:
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. Debatable if its against the Chandler philosophy or not.
I'll leave that issue open.
- 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
I see your point. You can be subscribed to an item read-only in one
collection and read-write in another, but they are the same item in
Chandler. So changes made to the item in the read-write collection
probably shouldn't be reflected in the read-only item, because its
read-only. Consider this scenario:
- User 1 publishes collection A with item aaa
- User 1 gives read-only ticket to User 2
- User 2 gets item aaa, modifies it and shares it in published
collection B
User 2 has read only access to aaa in collection A, but write access to
his copy in collection B. User 2 modifies his copy. What happens in
this case? Now there are two copies of aaa that aren't in sync because
one is read-only, but in Chandler its only represented as 1 item right?
-Randy
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
