Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

[Patrick Ohly <patrick ohly gmx de>]

On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote:
> On Wed, Jan 7, 2009 at 17:15, Patrick Ohly <patrick ohly gmx de> wrote:
> > The plan for change tracking is to get rid of the dependency on
> > e_book_get_changes(). I already stopped using e_cal_get_changes()
> > because it was too inflexible. Instead I'll rely on the REV resp.
> > LAST-MODIFIED properties: the backend must update these each time an
> > item is modified. This seems to be supported by most backends. Are there
> > backends which are known to not support this?
> 
> a) Looking at [1], I can't find what a REV property is. Did you mean
> to use [2] ?

REV is part of vCard 3.0. It would be used in ebook. ecal would use
LAST-MODIFIED instead. Does the GroupWise server update REV when
contacts are modified?

> > The problem with concurrent modifications is two-fold.
> > Stale data in UI:
> >      * user opens an item in Evolution
> >      * synchronization starts in the background
> >      * updates the item in EDS
> >      * => When the user saves his changes, will he overwrite the more
> >        recent data in EDS? Will he be warned? With Evolution the user
> >        is not warned and his changes overwrite the ones in EDS (tested
> >        with contacts). Evolution should listen for change signals and
> >        warn the user as soon as he has stale data in the edit dialog.
> >        The user then can cancel and reopen the item to redo his
> >        changes. This is unlikely to happen often, so more elaborate
> >        solutions (merging changes, additional buttons to copy from EDS)
> >        should not be necessary. Should I file a bug for this? Anyone
> >        able and willing to work on it?
> 
> Not so for calendars.

I only tested with a contact. There the problem occurs as described
above.

> > Stale data in sync:
> >      * when the sync starts, it builds a list of new/updated/deleted
> >        items
> >      * user modifies data in EDS
> >      * this leads to conflicts, f.i. sync modifies item that was
> >        modified by user
> >
> > Both cases need to be handled by the program which wants to make changes
> > to EDS data (Evolution, sync engine). To avoid race conditions, support
> > by EDS would be needed which currently doesn't exist. As a workaround
> > the following method would reduce the time window in which conflicts can
> > occur:
> >      * get revstring before starting to make modifications (when
> >        opening item in UI; when starting sync)
> >      * before modifying the item, check the revstring again
> >      * if the same as before, do the modification
> >      * if different, handle conflict
> 
> The GroupWise server updates the 'modified' property of the item when
> it actually gets modified on the server. For newly created items, it
> also adds the 'created' property at the same time.
> 
> This behavior invalidates all the 'handle-at-backend' approaches to
> fix the apparent bug,

"the apparent bug" =
https://bugzilla.novell.com/show_bug.cgi?id=184554 ?

Or do you mean the problem with overwriting more recent changes?

I'm not sure I understood how the GroupWise server and backend work.
What you are saying is that locally cached data might get out of sync
with the server and thus checks in the Evolution backend cannot be
implemented 100% accurately, right?

That sounds like a real problem, but I still see room for improvement.
For example, the backend could implement the workaround that I described
in my email. A client can't do that because without changes in the
backend it might read stale data, compare successfully, then push an
update which overwrites modifications on the server.

> > A secure solution would have to put the revision check into EDS itself
> > to make the check and update atomic. The proposal is to add this check
> > to e_book_commit_contact() and e_cal_modify_object():
> >      * The caller is expected to include REV resp. LAST-MODIFIED as
> >        read from EDS earlier.
> >      * The EDS backend compares against the current value before
> >        updating the item. If there is a mismatch, the update is
> >        rejected with a suitable error code.
> >      * If the values are unset, the update is always executed.
> 
> A backend may not have a LAST-MODIFIED property for a particular event
> in this use case:
> a) create a new appointment in the GW calendar (while online)
> b) open the same appointment (before the refresh timeout)

That's because the local copy of the appointment is not identical to the
one on the server, right? Perhaps the backend could force an immediate
refresh of this particular appointment to get the server's
LAST-MODIFIED?

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/