[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:       Holger Freyther <freyther () gmx ! net>
Date:       2002-01-23 13:44:04
[Download RAW message or body]

Am Mittwoch, 23. Januar 2002 13:57 schrieb Cornelius Schumacher:
> 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.
hmm I called it advanced libksync. I planing to fork your libksync and extend 
it in some ways. 
I need to take a deeper look into it then.
> > 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?
1. I'm not good in naming. 2. the some lines below
>
> > There's also a way to
> > configure a unit.
>
> What do you mean by unit? A (mobile) device?
not necessary a mobile device not neccessary a device. It  can your favorite 
cell phone, PDA, or even just a file plugin.
Ok libkunit is not the best thing to name it but I think libkdevicecomm is 
somehow good besides the device ( in contrast in KDevice )
>
> > 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).
Hmm libkunit/or libkdevice whatever will load the plugins internally. We do 
libkunit::load(the identifer we got from query )
>
> > 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"?
mainpulator plugin will be embedded inside KitchenSyncApp. Imagine it like a 
KCModule (KontrolCenterModule ) which does some configuration and maybe even 
status. Imagine a mail manipulator. You would want to choose which mboxes you 
wan't to sync and some other stuff. Or your favorite adressbook. Maybe you 
want to sync your cell phone with this file or your with this device. 
This makes me think that every device will have a unique identifer for all 
sessions or make KitchenSyncApp have profiles which is IMHO better

sync-plugin: the plugin for libksync which does the actual syncing.
>
> > 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.
hmm maybe I expressed it wrong.
I would like to see io-slaves just for the device. 
Then a unit-plugin. Let's say my Agenda Vr3 plugin would start a network 
connection but would use the actual io-slave for getting and writing the 
files. The plugin itselft would propagate the sync.
>
> 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.
I said I wish to see io-slaves for it

regards Holger
_______________________________________________
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]