[Cosmo-dev] another issue with items in multiple collections
Katie Capps Parlante
capps at osafoundation.org
Tue Aug 7 18:49:38 PDT 2007
To make sure I understand correctly...
- Item A is considered "modified" because it was added to collection 2
- When a remote/server modification is in conflict with a local
deletion, the remote/server modification wins (so the item is added back
to the collection)
- If the user removed it again (assuming no other changes happen) it
would stay removed
I'm guessing that when thinking through the case of "having the server
win", we were thinking of a scenario like this one: user A changes the
title of an event in the same sync cycle as user B deleting the event.
This one feels confusing/unexpected because:
- The same user is making all of the changes
- Moving an event to another collection doesn't necessarily feel like a
"change" to an item to the user
If I am understanding this correctly, I don't think this problem is a
server problem or even a mismatch between server and desktop
expectations -- its a desktop issue. We already knew about it in the
abstract, but this case gives us a concrete scenario that might affect
our thinking. The plan of record was to live with this behavior for
Preview -- conflict management was an 11th hour feature that we know is
imperfect (but more serviceable than not having any conflict management).
Proposal: continue with plan of record, relnote it for Preview. Revisit
it after Preview along with other conflict management improvements.
Morgen Sagen wrote:
> On 8/7/07, Randy Letness <randy at osafoundation.org> wrote:
>> I seem to be using this subject a lot.
>> Bug 10212 describes the issue:
>> To summarize:
>> 1. create collection 1, add item A
>> 2. create collection 2, add item A
>> 3. publish collection 1
>> 4. publish collection 2
>> 5. remove item A from collection 1
>> 6. sync collection 1 --> item A re-appears
>> This is occurring because the sync operation involves getting all the
>> updated records since the last sync (the publish in this case). When
>> collection 2 was published, it included the recordset for item A so the
>> server assumes A has changed. When collection 1 is synced, these
>> changes are sent back before the client sends the deletions and these
>> changes override the deletions and the recordset deletions never get
>> sent to the server.
>> I think this is just Chandler's policy, that is server changes always
>> override local changes.
> A remote update to a local removal is the only case in which a server
> change overrides a local change. Any other conflict goes through
> Chandler's conflict resolution framework. I did it this way because
> there isn't a UI affordance at the moment to indicate that a locally
> removed item has been changed on the server, and undoing the removal
> errs on the side of no-data-loss. Post preview we could certainly
> revisit this. Mimi, can you give some input as to what you would like
> the user experience to be for an item that has been locally removed
> but remotely modified?
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev