[Kde-pim] Syncronization issue with Akonadi

[Volker Krause]

On Wednesday 31 December 2008 16:46:06 Ingo Klöcker wrote:
> On Wednesday 31 December 2008, Stephen Kelly wrote:
> > Hi,
> >
> > 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.

> 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.

> 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/20090101/c71ac3b6/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/