[Kde-pim] Synchronization support for Akonadi

[Tobias Koenig]

On Thu, Oct 22, 2009 at 08:51:16AM +0200, Patrick Ohly wrote:
> On Tue, 2009-10-20 at 12:32 +0200, Ingo Klöcker wrote:
Hej Patrick,

> I second that. In SyncEvolution, I originally used the change tracking
> support provided by Evolution Data Server. It didn't quite fit the needs
> of SyncML, so eventually I replaced it with change tracking based on the
> REV (vCard) and LAST-MODIFIED (iCalendar) properties.
The REV and LAST_MODIFIED attributes are fragile, not all applications
reset them correctly when changing the objects...

> If Akonadi has efficient retrieval of ID/modification stamp pairs for
> all items in a database (and its my understanding that it has), then
> that's all that is needed for SyncEvolution and plugs nicely into the
> TrackingSyncSource.
Yes, Akonadi could provide exact ID/modification stamp pairs for all items
that are known to the system, indepentenly of their type.

>       * Depending on time stamps - is time 100% guaranteed to be linear?
>         Not in my experience.
Right, time might not be a good candidate, as there is no gurantee that the
clock has a resolution of microseconds, and seconds is not enough since for
a fast CPU a second is like an hour where much stuff can happen.
However, IIRC the synchronization only needs a so called synchronization anchor,
which can be a timestamp or an unique counter that is only increased.
The SLA can go with the latter and increase this counter on every synchronization.

>       * Keeping a log that is shared by apps. How do you know when old
>         entries are no longer needed? If you don't, the log will grow
>         infinitely.
The SLA should provide a 'per app' log, so the log can be flushed by the
synchronization application as soon as it doesn't need the log anymore.

>       * Keeping one log per app (as EDS does) that is flushed by the
>         app. Who deletes the log when the app gets uninstalled?
This is a damn good question... :)
We can't trust on the application here to cleanup the log I fear, so
the SLA is responsible for that. One way could be, that the application
registers itself with the path of its executable when creating a new log
( e.g. sla->createNewLog( 'uniqueident', '/usr/bin/evosync' ) ), then the SLA knows this log can be removed when the executable doesn't exists anymore.
Another way would be that the SLA removes logs that haven't been accessed for
more than 6 month or so...
The ideal solution doesn't exists here, I fear, so we have to choose the
best possible one :)

@Sascha so do you think it is worth to implement such a SLA for Akonadi?

Ciao,
Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091022/4f026988/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/