[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-24 9:05:36
[Download RAW message or body]

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

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

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

It's always a good idea to read a mail before sending. Don't forget that a 
lot of people are listening.

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