[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 22:05:10
[Download RAW message or body]

On Wednesday 23 January 2002 14:44, Holger Freyther wrote:
> Am Mittwoch, 23. Januar 2002 13:57 schrieb Cornelius Schumacher:
> > On Wednesday 23 January 2002 12:27, Holger Freyther wrote:
>
> 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.

Oh no, please don't fork a library, which is in such an early state of 
developement and hasn't been released up to now. Let's make it suitable 
for your application (and make your app suitable for libksync).

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

What about libksynccomm?

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

Please think about library dependencies. Somehow I don't like 
libraries, which dynamically load other libraries on request. That 
means that the library has to carry all the plugin loading stuff. As 
KitchenSync controls, which plugins to load, anyway, I don't see an 
advantage in moving the plugin loading code to the lib.

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

A manipulator plugin would bind a data type to a certain application, 
right? So that's something, which would come with KOrganizer for 
example and would let know KitchenSync that there is an endpoint for 
syncing calendar data and how to configure it.

Am I right that this is what a "conduit" is in "Palm-speak"?

> sync-plugin: the plugin for libksync which does the actual syncing.

Note that the actual syncing in terms of applying the algorithm is done 
by KSyncer, which is the same for all types of data.

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

What's the point in writing an KIO slave, if it only works, when other 
code has prepared the environment?

By the way: Reading your mails would be easier, if they would have more 
carriage returns and less typos ;-)

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