[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:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-01-26 10:18:40
[Download RAW message or body]

On Friday 25 January 2002 11:16, Andre Somers wrote:
> 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.

Yes, the Konnector does the communication/conversion. What I was trying 
to say is that the implementation of the Konnectors is the hard part of 
the syncing stuff and probably requires most of the time. Of course 
from a users point of view this should be hidden and also for the 
development of the syncing algorithm and the GUI the details should be 
well hidden behind an interface.

> > 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.

Yes, but in order to create concrete KSyncEntry objects you need to 
have an object of the underlying data (e.g. a KCal::Calendar). 
KitchenSync and libksync operate on the interface of the base class, 
but the data needs to be converted to a native object, before the 
syncing can be done.

> 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.

Yes, that's CalendarSyncee or BookmarkSyncee in kdepim/ksync/lib.

> > > 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?

The logfiles store the state of the data entries on the Palm when the 
last syncing has happened. So ksync knows, which entries have changed, 
which entries have been added and which have been removed.

> > > 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.

Yes.

> > > 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

That's the application, which provides the GUI, handles loading and 
configuring of the plugins and other f ramework stuff. It does no 
communication and no syncing by itself.

> KSync		The program actually doing the syncing

KSync currently is a standalone app, which is able to sync data on file 
basis.

> libksync	The backend syncing lib, used by KSync? Also contains the
> 		general objects below

Yes.

> 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.

Yes. I'm not sure if a konnector would be a "conduit", because I think 
conduit is usually used to refer to syncing a certain kind of data on a 
PDA with a desktop app.

> 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.

Yes.

> datatype	A class of data that needs to be synced. Examples: Adress,
> Calandar, ToDo, Mail, File and anything else you'd like to sync.

Yes.

> KSyncee	A container for KSyncEntries, forming the set of data that
> needs synchonisation. A KSyncee only may contain one datatype.

Yes. KSyncee also keeps track of the status of the synced entries (by 
writing log files).

> KSyncer	??? I would think this would be the same as Konnector as
> defined here?

KSyncer is the class that contains the actual syncing algorithm. It's 
part of libksync and operates on KSyncees.

> > > , 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?

The subclasses of KSyncEntry and KSyncee provide the required 
information to the syncing algorithm through the abstarct interface of 
KSyncEntry and KSyncee.

> > > 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.

Feel free to ask, if there is something not clear enough.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]