[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Yet another kde-pim proposal: libKSync
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-06-18 23:17:55
[Download RAW message or body]


I would like to throw in yet another proposal for the kde-pim 
architecture. I think it is complementary to the other  proposals, but 
is more focused at what we have now and how to evolve from there. I 
couldn't resist to also draw a diagram, see attachment.

What I propose is libKSync, a library for handling synchronisation of 
data like calendars and addressbooks. This lib provides synchronisation 
logic operating on abstract Sync classes (e.g. an algorithms to resolve 
conflict by scanning data entries, checking if they are equal or have 
changed, resolving conflicts according to the preferences of the user, 
logging data modifications etc.). The abstract Sync classes provide 
functions for determining, if entries are equal, return unique 
identifiers, copy data, etc.

To be useful the abstract Sync classes have to be subclassed by 
concrete Sync classes operating on the specific data objects for 
calendar, addressbook or any other concrete data. That means the 
overall sync logic is only implemented once and the data specific logic 
is implemented once per data type.

For representing a data type there is one class for each type. There is 
a class for calender data, a class for addressbook data etc and the 
good thing is, that we already have this classes in libkcal and libkab.

The KDE-PIM applications operate on these data classes. There are apps 
that have full viewing and manipulation capabilities like KOrganizer 
and KAddressBook and others, which are mainly for reading/writing data 
from other devices. But they are all similar in one respect, they take 
data from a source and store it in an object of the corresponding data 
type. The source can be a Palm Pilot, an iCalendar file, libkab, a 
server, whatever and the access to this data can also vary, e.g. per 
serial interface or USB, per kioslave, per some sort of server access 
over the network. The mechansim how to access the data in combination 
with the handling of the format of the data and the conversion to the 
standard object for a type is a conduit.

Let's take an example of a synchronisation process: KOrganizer would 
like to synchronize a local calendar file with a file on an FTP server. 
So it loads both files into Calendar objects and then uses libKSync to 
bring them in sync, it then stores them back to their original 
locations. Another example would be syncing of Pilot data with 
KOrganizer. Here KOrganizer would ask KPilot for the data, would then 
perform the sync with libKSync and ask KPilot to write the synced data 
back.

The control of the syncing process needs not to be in a specific 
application. Currently it is implemented this way, but it is possible 
to put this functionality into a separate Syncer application 
(KitchenSync?), which is accessed via DCOP or something similar.

What are the benefits of this architecture?
- It reduces duplication of code. Syncing algorithms and functions to 
convert data formats would be seperated and only implemented once per 
data type.
- It is extensible. Adding a new device or format (e.g. XML) is only a 
matter of implementing the conversion to the standard data object.
- It is reusable. The syncing lib could also be used in a server, which 
has to sync data (e.g. a SyncML server)

What is necessary to implement this?
Most of the code is already there.  In some cases it even is there 
multiple times like the syncing algorithms used by the different KPilot 
conduits and Kandy. We only have to rearrange and clean up the code, add 
the abstract interface classes and implement what is missing in terms of 
syncing functionality.

That's it for now. What do you think? Questions and comments are very 
welcome.

-- 
Cornelius Schumacher <schumacher@kde.org>

["ksync.ps" (application/postscript)]

[prev in list] [next in list] [prev in thread] [next in thread]