[Kde-pim] Synchronization support for Akonadi

[Ingo Klöcker]

On Tuesday 20 October 2009, Tobias Koenig wrote:
> Hej,
>
> during the weekend Sascha told about his work on the SyncML
> support for Akonadi and mentioned that an important property
> is missing in Akonadi to make implementation of synchronization
> software easier. Synchronization software has to be aware of
> changes in the data storage since the last synchronization,
> so if Akonadi would provide methods like
>
>   Akonadi::Item::Id::List newItemsSince( const QDateTime& ) const;
>   Akonadi::Item::Id::List changedItemsSince( const QDateTime& )
> const; Akonadi::Item::Id::List deletedItemsSince( const QDateTime& )
> const;
>
> it would makes implementors life much easier.
> The bad news are that the Akonadi server doesn't support the tracking
> of these changes itself, the database only stores the last
> modification date of an item. However the good news are, that there
> is no need that Akonadi keeps track itself. The tracking of changes
> and keeping a log of them can be done by a separated agent
> application that is always started together with the server. So this
> SLA (Synchronization Log Agent) can on the one side listen to all
> changes in the storage via Akonadi::Monitor and on the other side it
> can provide a DBus interface to request informations like the above
> ones. The SLA can store the item ids of deleted items in its log file

Its log file? What log file? Please store it in a database file probably 
even in the Akonadi database.


> and could provide profiles, so that different synchronization
> applications can have its own synchronization history (e.g. app A
> synchronized last today and app B on wednesday last week).

That's not sufficient and also not what's needed. What's really needed 
is the sync history between any two storages (for lack of a better 
word) that were sync'ed. This is completely independent of the 
application(s) that are used to perform the synchronization.

I'm wondering whether it wouldn't be better if each sync app would 
provide its own custom tailored SLA. Of course, we could provide a 
primitive SLA that could be used as template, but I doubt that we can 
provide an SLA that fits the need of all sync apps.


> Furthermore it can optimize changes (e.g. removing a 'new item'
> followed by a 'delete item' event with the same id) to reduce the
> amount of data that have to be synchronized.
>
> What do you think about it?
> Sascha, what additional functionality would you need?


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091020/28205a34/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/