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

List:       kde-pim
Subject:    Re: [Kde-pim] synching framework in kde (long)
From:       Andre Somers <a.t.somers () student ! utwente ! nl>
Date:       2002-01-25 10:16:12
[Download RAW message or body]

On Thursday 24 January 2002 23:23, Cornelius Schumacher wrote:
> On Thursday 24 January 2002 15:31, Andre Somers wrote:
> > Case 1: the syncing of two objects
> >   1) Get a list of additions, modifications and deletions since the
> > last sync 2) Add all additions to the other device
> >   3) Scan list of modifications and deletions for records that are
> > modified on both devices, and resolve these problems (this may be
> > resoved using a setting to prefer the Palm in such cases, or by
> > displaying a dialog to the user and have him resove the conflict)
> >   4) Commit the modified records to the respective devices and
> > execute the deletions.
>
> That's a part of a syncing process, but you are missing the
> communciation/conversion part. [...]
No, I was abstracting from that :-)
The communication/conversion is, in my view, something that has to be done by 
the what I here have called Konnector (the plugin, the conduit). In designing 
an architecture for a general syncing system in KDE, I think it's wise to 
abstract from these things for starters.

> You have to convert this into objects, ksync and the KDE
> programs can handle. That means converting the pilot-link (in this
> example) structures into KABC::KAddressbook or KCal::Calendar objects.
I would NOT use these in this stage. The data to be synced should IMHO be of 
some abstract datatype that K(itchen)Sync can handle (compare it's last 
modified date, get from the Konnector and send to the Konnectors that need to 
incorporate this data into their own, private backend datastructures). I 
think it would be easiest if these data-units (KSyncEntries right?) would be 
decendants of some general class, and need to implement a few basic 
memberfunctions that allow K(itchen)Sync to handle it: a flag what has 
happend to this record (new, modified, deleted), an ID and a date when this 
has happend would be minimal, I guess.
The different Konnectors should worry about converting the data contained to 
something their backends can use. You do however need to define a standard 
subclass of the KSyncEntry for each datatype to be synced, so that 
devellopers can use that for their own backend.
>
> > ad 1. In order to be able to get this list, a Konnector must be able
> > to know which records are modified. 
> This is addressed by the log files of KSyncee.

? How is that? How can a logfile adress datachanges on, say, my Palm?

> > Conflictresolving is an important part of the syncing I think. 
>
> Conflict resolving is the job of libksync. There is already a conflict
> resolving UI. It could also be replaced by something automatic like
> "The Palm is always right".
Well, I think the user should be able to choose, per datatype, how he wants 
to handle conflicts. That may be automatic in some cases, but not allways.
>
> > There are many more datatypes imaginable that can be
> > synced. KitchenSync should abstract the syncing process from the
> > datatypes itself and be able to sync any type of data.
>
> Yes, the konnector has to knwo what data types it can access and tell
> this to KitchenSync in a generic way. KitchenSync then takes care to
> find the appropriate plugins (or conduits) to the KDE appliciations.

Errr.... ok, I think we have a mixup of names here.... I might not have have 
understood the names of all entries correctly. Shall we try to clarify that 
first? 

Here's what I understood so far, I welcome all additions and corrections:

KitchenSync	The general syncing framework for KDE
KSync		The program actually doing the syncing
libksync	The backend syncing lib, used by KSync? Also contains the
		general objects below
Konnector	A 'plugin' or 'conduit' that plug into the KitchenSync framework.
		It forms a 'bridge'  between the backend data it wants to synchonize and 
		KSync, offering a the latter methods to retreive and store data for the 
		syncing process. All translation/communication with the backend device or
		service is done by the Konnector or by other programs or libraries called
		by it. The Konnector just offers the services needed for syncing to KSync.
KSyncEntry	A unit of data to be synced. This is an abstract datatype defined
		in libksync. It offers a basic interface for data needed for the syncing
		process itself (like a flag 'new', 'modified' or 'deleted'  and a
		modificationdate) and is subtyped for each datatype to be synced to a
		type supported by all Konnectors that want to sync this datatype.
datatype	A class of data that needs to be synced. Examples: Adress, Calandar,
		ToDo, Mail, File and anything else you'd like to sync.
KSyncee	A container for KSyncEntries, forming the set of data that needs
		synchonisation. A KSyncee only may contain one datatype.
KSyncer	??? I would think this would be the same as Konnector as defined here?


> > , and b) data needs to be 'packaged' in an
> > object that KitchenSync can handle (I believe we agreed to call these
> > KSyncEntries).
> No, KSyncEntries are entries of a certain data types belonging to a set
> of data to be synced. The set is called KSyncee, if it is used by
> libksync. The normal first step would be to put this data in its native
> object like Calendar or Addressbook.

How, in that case, can KSync or libksync access the data it needs to decide 
how to sync this data? In order to sync a couple of sets, one needs at least 
an ID, a flag what happened and a date/time when it happened, right? If the 
data is in some native format, how can this data be accesed by the syncing 
process? OTOH, if you use a KSyncEntry object that features this needed 
information and can serve as a store for the data itself, you have no problem 
here. Of course, you can keep the subclassing very simple and just add a 
string member containing a vCard for adressbook data or a piece of data in 
iCalendar format for your Calendar application. Konnectors (in the sence 
defined above) for devices or services using this format natively can be 
quite simple in that case, right?

> > So, we have a general KSyncEntry that must be
> > subclassed per datatype (for instance KAdresSyncEntry) and may in
> > it's turn be subclassed by each Konnector to suit it's private needs,
> > for instance for reading and writing the data to it's backend format.
>
> Yes, have a look at kdepim/ksync/lib for some examples of KSyncee
> subclasses.
OK, I will. I hope I can understand it.


Andre
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]