[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 11:18:12
[Download RAW message or body]

Am Donnerstag, 24. Januar 2002 10:05 schrieb Cornelius Schumacher:
> On Thursday 24 January 2002 01:02, Holger Freyther wrote:
> > 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
>
> Why not? Just make a link of the directories, if you don't want to install
> kdepim. 

I've kdepim always installed. This wasn't meant to apply for me but for 
others who want to check out kdepim. But I just recognized this argument is 
void as well ( you would want to have korganizer... )
> But please work on KSync in the kdepim module of the KDE CVS. It's
> a waste of time and energy to work on two branches of the same code, if it
> isn't necessary. And in this case it's not necessary at all.

>
> > > What about libksynccomm?
> >
> > hmm not even better. Actually we don't do any syncing inside this lib.
> > What's about libkommbackend?
>
> As I just wrote in another mail, I think, the best name would be to call it
> libkconnector. Connector is the right name for the device-specific
> KitchenSync plugins.
I will adopt the name.
>
> > > > > 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.
>
> Ok, but you are talking about KSyncee not KSyncEntry. KSyncee represents a
> set of data of one certain type.
I had a quick look at your lib and first of all your comments are always 
excellent.
Why do we need KSyncee for KitchenSync. What does KSyncee provide more than a 
iterator does? Simply it provides some basics to write logs to save the 
files. But why do I want to save a file if you access a pda? This would be 
the task of the manipulator plugin. 
The log could be returned form libksync by a simple return value
class KSyncReturn {
public: 
  KSyncReturn(const QString &, QPtrList<KSyncEntry> );
QString  log() const;
QPtrList<KSyncEntry> entries() const;  
private:
QString m_log;
QPtrList<KSyncEntry> m_entries;
};
I propose a 2nd Interface to libksync which could be used by KitchenSyncApp. 
Personally I would drop KSyncee. KSyncer algorithms would be loaded by 
libksync itself.
Ok then I will develop it inside kdepim. Can I just commit any changes or 
should I talk to you first?

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]