[Kde-pim] Syncronization issue with Akonadi

[Volker Krause]

On Friday 02 January 2009 14:43:09 Stephen Kelly wrote:
> Volker Krause wrote:
> > On Thursday 01 January 2009 17:13:20 Stephen Kelly wrote:
> >> Volker Krause wrote:
> >> > 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.
>
> OK, that's all clear now. I'm keeping notes of this in the extended apidox
> I'm writing in kjotsrewrite/akonadi_next.

Perfect, thanks :)

> However, I did think of another conflict situation. The above one depends
> on a race condition when akonadi already knows about a change in an item a
> user is editing, but I think this one is a bit different.
>
> Imagine Alice is out of office for the day, and while disconnected, she
> updates an address as above. Meanwhile, Bob is still in the office and he
> changes the address to, as above. Revision numbers match up, so there is no
> conflict.
>
> When Alice gets connectivity back, two things will happen. Her akonadi
> server will get notified that the address has changed, and her resource
> will notify the groupware system that she has updated the address of the
> contact. The order that those two things will determine what happens. If
> she retrieves changes from the groupware system first, her changes will be
> overwritten (unless the revision number can help there too?). If her
> resource notifies the groupware system first, Bobs changes there will be
> overwritten.
>
> This could happen while neither Alice nor Bob have any kind of address book
> system open, so no application would necessarily be able to notify either
> user even it is possible. I think the conflict would be silent though. To
> the Akonadi servers on both Alice and Bobs machines, everything is
> happening as expected.
>
> Is this a plausible scenario?

It is. How to handle that correctly depends a bit on how the groupware server 
handles conflicts. If it doesn't provide any way to detect that, Akonadi (and 
any other client) might indeed overwrite changes on the server that happend 
inbetween. The other direction can be handled by the resource though. Like in 
the conflict scenarios discussed earlier, the application triggering it (the 
resource) is responsible to dealing with that. That's one reason why 
resources are actually GUI applications and can bring up dialogs.

For detection, given no server side support, we might need a "remote revision" 
property per item that contains the revision of the last change synced with 
the backend. Changes from the backend would then considered conflicts if the 
item revision is higher than that remote revision, ie. there are unsynced 
local changes. Not sure if there is a backend at all that doesn't provide any 
help with this though.

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/3c4fca3d/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/