A couple of additional suggestions

[Martin Konold]

Am Monday 16 August 2004 15:38 schrieb Stuart K. Bingë:

Hi,

> How exactly is this currently handled, i.e. what happens when a
> disconnected client syncs, modifies an object, tries to sync again, and
> realises that the object was modified by another client between the two
> syncs?

The client shall first fetch all new messages/flags and then check its 
"outgoing queue" for conflicts and act accordingly (e.g. conflict 
resolution). 

A stupid client (allowed for now!) not beeing able to follow this procedure 
leads to doubling of messages in case of conflicts. 

These conflicts are then visible to the user and need manual resolution.

> I would think it should cancel the object edit/save, reload the (new)
> modified object, perhaps update the fields that were previously modified by
> the user before syncing (i.e. merge the newly loaded object and the
> user-edited object), and then resave after a user confirmation.

Yes, this is a possible client side conflict resolution mechanism. Though this 
is not always that simple. E.g. the merge fails in case two clients modified 
the same attribute at the same time.

> In this case the revision tag can work reliably. Unless this scenario that
> I described is totally off...

By definition we never have any lock! This leads to the fact that there is 
always a window of opportunity that we miss an intermediate update.

Conclusion: The revision number works most of the time but is not reliable.

> There's a problem if the edited object no longer exists at the second sync,
> however. How is this case currently handled?

If the modified object got deleted in the meantime the same conflict 
resolution rules apply. Deletetion is not different from modification in this 
respect.

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold at erfrakon.de