[Kde-pim] Syncronization issue with Akonadi

[Stephen Kelly]

Volker Krause wrote:

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

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?

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


regards,

Steve.

_______________________________________________
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/