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

List:       kde-pim
Subject:    Re: [Kde-pim] RFC:KitchenSync Are you ready for syncing?
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-01-23 12:57:19
[Download RAW message or body]

On Wednesday 23 January 2002 12:27, Holger Freyther wrote:
>
> KSyncEntry is a base class for all SyncingOperations.
> It have a QString type() and a uuic method QString uuid() not more at the
> moment.

If you are talking about the libksync class KSyncEntry this is not quite 
correct. For each data type you want to sync you have to implement two 
interfaces: KSyncEntry, which represents an individual entry, and KSyncee, 
which represents the set of data entries to be synced. A third class 
(KSyncer) operates on these two classes and performs the actual syncing 
algorithm.

All these classes exist and work and can be found at 
kdepim/ksync/lib/ksyncer.h.

> Then there will be libkunit which expose functions, slot, signals for
> propagating syncs, writing, getting KSyncEntries.

Can we find a better name than "libkunit"? As I understand it, what you call 
libkunit would be the communication backend to the devices, which are to be 
synced, right?

What about "libkdevicesync" or "libkdevicecomm" or something like that?

> There's also a way to
> configure a unit.

What do you mean by unit? A (mobile) device?

> On startup KitchenSync will query(const QString
> &category). Where category is the wished category of the device (PDA, file,
> Cell-Phone...). Then KitchenSync will ask the user which ones to use and
> then kindly ask libkunit to load the plugin which then returns a unique id
> which lasts only for the runtime. KicthenSync needs to remember this id
> cause it will be used for all operations.

In other words: KitchenSync will be able to sync with multiple devices. The 
user tells, which devices to be used, and KitchenSync loads the required 
libraries and offers whatever GUI elements are needed for that device 
(perhaps not much more than a status display in many cases).

> KitchenSyncApp will then one time get a wantsToSync( int id ). The signals
> comes from the libkunit plugin and will get emitted by libkunit.
> KitchenSyncApp will then get the QValueList<KSyncEntry> and checks the type
> if a manipulator plugin is installed libksync will be called to load a sync
> plugin.

What's a "manipulator plugin"? What's exactly a "sync plugin"?

> What gis proposed firsrt and I'm propsoing now is to make libkunit plugins
> a IO-Slave with additional features inside the libkunit.

A KIO slave is not a plugin. It starts an external process. As we discussed 
in the past it might not be possible to implement communication with a mobile 
device by an KIO slave. The example was the Palm Pilot, which needs the sync 
button to be pressed, before any data can be read.

For many cases it's probably too much overhead and not flexible enough to 
implement communication to a device as a KIO slave. I don't say that using 
KIO slaves is a bad idea, but I would propose to make a special plugin, which 
provides the capability to use KIO slaves, but it shouldn't be required 
that all communication is done by KIO slaves.

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