[Kde-pim] Synchronization support for Akonadi

[Ingo Klöcker]

On Tuesday 20 October 2009, Tobias Koenig wrote:
> On Tue, Oct 20, 2009 at 12:32:33PM +0200, Ingo Kl?cker wrote:
> > On Tuesday 20 October 2009, Tobias Koenig wrote:
>
> Hej Ingo,
>
> > > 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.
>
> Yes, of course, that's an implementation detail anyway :)
>
> > > 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.
>
> Yes, of course, the SLA should provide a generic way to provide such
> profiles. So if the user wants to synchronize its iPhone with
> Akonadi, the synchronization application would request a new profile
> from the SLA with a unique identifier. The identifier is opaque to
> SLA, it must however be unique. Then the synchronization application
> does the initial slow sync. From that point on, the SLA keeps track
> of all changes in Akonadi and writes them to the profile log. Later
> on, the user wants to synchronize its N810 with Akonadi, so the
> synchronization application requests a new profile from the SLA and
> the SLA will start writing change information to this profile as
> well.
> Now the user wants to sync his iPhone again, so the sync app will
> choose the iPhone profile from the SLA and ask for all changes
> between the last (initial) sync and the very moment. After this fast
> sync, the SLA can drop all change information for this profile he
> kept until now and start logging again. The profile of the N810 is
> not effected by that.

Note that this approach will break down as soon as three storages are 
synchronized with each other (as opposed to two storages being 
synchronized to a third "master" storage), i.e. let's say you have a 
desktop, a laptop and a phone. Before you leave home you sync the 
laptop with the desktop. On the train you are bored and start to clean 
up your address book (you delete some contacts, you categorize others, 
you remove obsolete phone numbers or addresses, etc.). Then you sync 
your phone with your laptop. After you return home you want to sync 
your phone with your desktop. Obviously, the data stored in the profile 
of the phone is now pretty useless because it does not reflect the 
actual sync state of the phone. Blindly replaying the changes stored on 
the desktop (that have already been pushed to the phone when it was 
sync'ed with the laptop) would likely create a mess in the phone's 
address book.

Just something to keep in mind.


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/4858cde0/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/