[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-24 0:02:23
[Download RAW message or body]

Am Mittwoch, 23. Januar 2002 23:05 schrieb Cornelius Schumacher:
> 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).
Ok but I need to check it in kdenonbeta though. I would like to keep the 
source together. In this early stage I don't want to rely on kdepim
>
> > > > 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?
hmm not even better. Actually we don't do any syncing inside this lib. What's 
about libkommbackend? 
>
> > > 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.
With "my" libksync KitchenSyncApp will receive a QPtrList<KSyncEntry> (Ptr 
will only work though or can the &operator= be virtual? If it can be virtual 
then we can use QValueList ). Then we would iterate through the list and see 
for which types() const we do have "manipulator plugins/visuals" loaded. 
KitchenSyncApp keeps two lists for each KommBackEnd. One called incoming and 
one called outgoing. Every KSyncEntry for a type which is not installed is 
automatically moved to the outgoing list. then the QPtrList<KSyncEntry> gets 
split up per type and passed to the manipulator plugin which then processes 
the data. It passes it on to libksync and gets a KSyncEntries back. After 
doing this the KSyncEntries will go to outgoing list and after all plugins 
got the possibility to sync their KSyncEntries will be passed to 
libkunit/libkommbackend.
When having the data flow this way I want libs for KSyncEntries and for the 
KSyncs sync algorithm. Then either libksync or the manipulator plugin can 
load the KSync algorithm. Actually I prefer the algorithm to be loaded by 
libksync.
libkcommbackend plugins can link to the KSyncEntry library. 

> > > > 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?
Yes and No. Lets take mail as an example. With a manipulator plugin you could 
configure which Mailboxes to sync with. Which alias to associate with an 
email Address. Or it could show your local Mailboxes and ask you to copy 
mails to your KCommBackEnd.
For the AddressBook it would just want to know the path and maybe the sync 
mode.
Best would be if the Applications provide such plugins.

> By the way: Reading your mails would be easier, if they would have more
> carriage returns and less typos ;-)
                                       ^^^^^
Hm, this would make me to use either a spell checker or to reread my mail.....
I guess my brain is just too fast.... :)
I'll try to improve it though.....

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]