[Kde-pim] Syncronization issue with Akonadi

[Volker Krause]

On Thursday 01 January 2009 17:13:20 Stephen Kelly wrote:
> Volker Krause wrote:
> > On Wednesday 31 December 2008 16:46:06 Ingo Klöcker wrote:
> >> On Wednesday 31 December 2008, Stephen Kelly wrote:
> >> > Imagine an addressbook application which has a list of contacts and a
> >> > contact editing widget on the other.
> >> >
> >> > You are editing the address of the contact when an akonadi monitor
> >> > notifies the application that that contact has changed on the server.
> >> > For example, when you started editing the address it was
> >> >
> >> > 123 Fake Street,
> >> > Silly Lane,
> >> > Essen.
> >> >
> >> > You edit the first line so that it is
> >> >
> >> > 321 Real McCoy Street,
> >> > Silly Lane,
> >> > Essen.
> >> >
> >> > Before you save it, akonadi notifies the application that that
> >> > address is now
> >> >
> >> > 456 Conflict Street,
> >> > Silly Lane,
> >> > Essen.
> >> >
> >> > What is the application supposed to do? Offer a merge dialog?
> >> >
> >> > I think there may be other similar conflict situations. Has anyone
> >> > thought of what applications should do about this yet?
> >
> > The Akonadi server provides conflict detection, in your example that
> > means the application would ignore the change notification would just try
> > to write its own changes. Akonadi detects that using the item revision
> > number but leaves handling that case entirely to the client.
>
> Hmm, I understand what you mean about akonadi detecting conflicts, but I
> don't see any way for it to report a conflict to the application. If the
> application is going to handle the conflict, it has to either be told about
> it, or not ignore the change notification, right?

In case of a conflict (revision number on the server differs from the one used 
by the client), the ItemModifyJob fails with a corresponding error. That's 
all the reporting that happens from the Akonadi side. The application that 
tried to store the change then has to handle this case, eg. it could fetch 
the new version from the server and show a merge dialog for the two ones.

Note that this is independent of ignoring change notifications, even when 
listing to them there is a small time window between receiving the 
notification and storing your changes where you still could run into this. 
Also, a change notification while editing an item probably needs the same 
kind of conflict resolution, it's just detected earlier.

> >> AFAIK each time we discussed this we came to the conclusion that
> >> handling such conflicts is out of scope for Akonadi. It has to be done
> >> by the applications because they know much better what the user has
> >> done.
> >
> > The second reason is that the available options are usually highly
> > type-dependent, therefore being out of the scope of the type-independent
> > Akonadi core.
>
> Yeah, what I meant by merge dialog was something like a dialog with what
> akonadi knows about on one side, your proposed update on the other,
> conflicting fields marked, and an opportunity to change the update you are
> making.
>
> >> The applications should probably do the same as Kate/KWrite when
> >> noticing a file the user is currently editting has changed on disk.,
> >> i.e., the applications should ask the user whether he wants to discard
> >> his changes or whether he wants to ignore the other changes. Offering a
> >> complicated merge dialog for a situtation which doesn't occur very
> >> often is, IMO, overkill.
> >>
> >> Maybe it makes sense to allow the user to store his changes in a new
> >> item (similar to Save As). Then the user could examine the differences,
> >> make the necessary adjustments and discard the other item. Hmm, this
> >> could break links of other items to the original item in case the user
> >> decides to discard the original item instead of his changed "Saved As"
> >> item. So maybe some kind of merge dialog is the better solution.
> >> (TortoiseSVN has a pretty good merge dialog but, of course, merging
> >> text files is trivial compared to merging structured data.)
> >
> > Once we know how we want to handle those cases exactly it probably makes
> > sense to provide the corresponding functionality in the type-dependent
> > client libs, giving us easy and consistent conflict handling in all apps.
> >
> > Also, I vaguely remember some type specific diff code for kabc/kcal in
> > libkdepim.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090102/52ea0d80/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/