[Kde-pim] Synchronization support for Akonadi

[Sascha Peilicke]

On Tuesday 20 October 2009 12:32:33 Ingo Klöcker wrote:
> 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;
> >
> > [..]
> 
> 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).

I think this belongs into the sync agent that really needs this. For example, 
a SyncML server agent would want to store when he was last accessed 
(successfully) by a particular client (e.g. a cellphone device), but that 
should not be made available as data inside Akoandi. This is unnecessary for 
most other agents.

> 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.
This might be to much than what is actually needed, at least for the SyncML 
agent. In that particular case I only care for what has changed in a certain 
Collection since a specific point in time. How that was done or which other 
Agents/Resource/Remotes where involved is unimportant. However, I do agree 
that this might be useful in the future.

> 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.
This seems to be what is currently done in some places, but has some serious 
drawbacks. What happens when Agents crash or when the internal Akonadi 
database is getting reorganized (backend change for example)? The agent would 
have to take track of each and everything, which is actually the role of the 
Akonadi server. Furthermore we would have multiple storage places again. And 
how should an Agent do that? Using a personal database to guarantee integrity? 

> > 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?
From an Agent implementors side, the 3 proposed methods (as part of the 
Collection class) would suffice / make my live easier :-)
-- 
Sascha Peilicke
http://saschpe.wordpress.com
-------------- 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/4a422a8e/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/