[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 23:08:39
[Download RAW message or body]

Am Donnerstag, 24. Januar 2002 22:56 schrieb Cornelius Schumacher:
> On Thursday 24 January 2002 12:18, Holger Freyther wrote:
> > Am Donnerstag, 24. Januar 2002 10:05 schrieb Cornelius Schumacher:
> > > 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?
>
> KSyncee represents a set of entries. You need it and you also need the
> log files to detect, which entries have been updated, which have been
> added and which have been removed. That's much more than an iterator.
why would we need it( do we want to make it private? or chat in #kitchensync?)
> It could also provide some information about the data type, if that
> would be useful.
I want to add a type() const in KSyncEntry.
>
> > 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?
>
> Because you have to remember, which entries you already have synced.
What about having three lists. We would get two QPtrList<KSyncEntry> as 
parameters and we would have one internally which will be returned. Every 
synced entry will be moved to the internal list. 

> You need that information on the side doing the syncing in order to
> recognize, which entries have changed and which entry is more current
> than another (plus recognizing which entries have been deleted or
> added).
every entry which isn't copied if one of the lists is iterated will be 
appended to the outgoing list.
>
> > 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;
> > };
>
> What's the difference between KSyncReturn and KSyncee? KSyncee is
> needed by KSyncer to perform the syncing. I don't see a need to drop it.
>
> > I propose a 2nd Interface to libksync which could be used by
> > KitchenSyncApp. Personally I would drop KSyncee.
>
> libkonnector and KitchenSync could use KSyncee. An alternative would be
> to use the native classes like KCal::Calendar or KABC::Addressbook and
I want to use natvice classes. but having a KSyncEntry which will do the 
transporting. the libkonnector plugins will have to convert from the native 
format to kdes ones.
> make the conversion to KSyncee in libksync.
I have a different dataflow in mind.
libkonnector will pass QPtrList<KSyncEntry> on demand to KitchenSyncApp or 
any other app. KitchenSyncApp will traverse this list of KSyncEntries and 
decide by type which manipulator plugin to be used and pass them on to it. 
These manipulator plugins will then pass the QPtrList<KSyncEntry> and another 
 QPtrList<KSyncEntry> (to be configured inside the manipulator plugin) to 
libksync.
What I want from libksync is I want to pass two QPtrList<KSyncEntry> to 
libksync and say which mode to use and get back a single QPtrList


enum { KONNECTOR_TO_DSK=1, DSK_TO_KONNECTOR=2, INTERACTIVE=4, 
NONINTERACTIVE=8 };
class KSyncResult;
class ZeckesKSync {
public:
ZeckesSync();
   KSyncResult sync(QPtrList<KSyncEntry>, QPtrList<KSyncEntry>, int modus );
void AsynSync( QPtrList<KSyncEntry>, QPtrList<KSyncEntry>, int modus);
signals:
processed(QPtrList<KSyncEntry> );
done(KSyncResult );

};
I just would pass QPtrLists to KSync and would get a single QPtrList back 
which then can be saved where I want to save it.
It would be the detail of libksync how to do it actually.
>
> > KSyncer algorithms
> > would be loaded by libksync itself.
>
> KSyncer is part of libksync. Currently there is only one algorithm and
> I don't see the need to add another one.
libkonnector loads libkonnector plugins.
libkonnector plugins need to link against specialised KSyncEntry ( 
KBookmarkSyncEntry, or KWordSyncEntry )
KitchenSyncApp is a framework which KicthenSyncApp-Plugins ( modifier 
plugins/ visuals )
the modifiers will link against  their specialised KSyncEntry
libksync will have plugins which will do the actual syncing. 
These plugins will be loaded by libksync on demand.
The plugins will link against their specialised KSyncEntry as well.

What do you have todo to add a new  datatype:
You would need to write a KSyncEntry and make it a lib. Then you would need 
to extend the konnector plugins and write a libksync algorithm plugin for the 
real syncing.

This makes me think of a detail. Either the konnector plugins support plugins 
as well or we do have some post-processor which can perform on a plugin. like 
fetching a QByteArray from a plugin and try to convert it to a KSyncEntry. I 
need to think about it  a bit more though. This would be just a minor detail 
and could be easily added when the framework is done.



> > Ok then I will develop it inside kdepim. Can I just commit any
> > changes or should I talk to you first?
>
> You can just commit, but keep in mind that there is a working
> application ksync/src/ksync. It would probably be good to announce
> major changes on the mailing list, so that we can comment on it.
> Another complication is the message freeze for the KDE 3.0 release. If
> required we can make a CVS branch for ksync.

a branch would be good

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]