On Thu, 2009-01-08 at 10:49 +0100, Patrick Ohly wrote: > On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote: > > On Wed, Jan 7, 2009 at 17:15, Patrick Ohly <patrick.o...@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.
As suman had mentioned, this is not a problem for calendar as the modifications are notified to the UI by matching the live queries in place. > > > > 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? You are right. This is a problem in groupwise backend and not common to all backends. We should be storing the last modified time stored in server as soon as the item is created. There is a problem in the groupwise soap interface that it does not return the created/last-modified time stored on server after creating the item. May be the item has to be fetched again to get these fields. But this is a problem only to groupwise and should be fixed in the backend. thanks, Chenthill. _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
