[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] synching framework in kde (long)
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-01-26 10:32:19
[Download RAW message or body]

On Friday 25 January 2002 13:09, Andre Somers wrote:
> On Friday 25 January 2002 11:16, Andre Somers wrote:
> >> > Yes, have a look at kdepim/ksync/lib for some examples of
> >> > KSyncee
> > >
> > > subclasses.
> >
> > OK, I will. I hope I can understand it.
>
> So... I did browse through the ksync (header) files, and found that
> they pretty much look like what I had in mind :-)

I think so. Your earlier comments fit quite well to the stuff, which 
alread is there ;-)

> Still, I have a few remarks/questions about what I've seen....
>
> 1) About the conflictresolution:
> I see that UI interface is requiered to solve conflicts (with a
> default 'don't sync at all of none is provided). However, I think
> that all such dialogs would essentially look the same: like a set of
> radiobuttons giving the user a choise which one to prefer or to skip.
> So, why not make a generic dialog? Furthermore, the functioncall you
> provided for the UI only accomodates two entries. If multiple
> devices/services are synced, don't you need as much entries to be
> shown in the UI to give the user a good choice? This brings me to
> another problem here: the dialog would need to be changed every time
> more konnectors for this dataclass are added. That is not feasable,
> I'd say.

No, the dialog operates on the abstract type KSyncEntry of libksync, 
which is the same for all kind of data. So the dialog already is a 
generic dialog. To provide a dialog for syncing more than two entries 
would be overkill at the moment, I think. Things are already complex 
enough ;-) You can always sync multiple data sets by a sequence of 
two-way syncs.

> I would like to propose another solution: have each konnector
> register itself with the datatypes it supports in ksync. Ksync can
> now dynamicly generate a configuration dialog per datatype, giving
> the user the opportunity to set a default conflictresolution ("the
> palm is allways right") or have the system ask for a resolution on a
> per-case basis. If the latter is the case and a conflict occurs,
> KSync can again generate it's own dialog (basicly the same as the one
> used for the configuration, replacing the "ask user" option with a
> "don't sync" option). In this way, the dialog allways can display a
> choise for all the parties involved in the sync, without having to
> change the dialog for each new datatype or konnector. An added
> feature that would be very usefull would be to have the lib for the
> datatype (dataclass) provide a UI widget (much in the same way you do
> now) that can display the data for the specific datatype, that can be
> integrated into the standard conflictresolution dialog by KSync.

The code already does what you want. It's exactly waht I also had in 
mind. Providing data-type specific dialogs would be a nice extension, 
but at the moment I think the generic dialog is ok. Let's make one step 
after the other.

> 2) About the KSyncee class
> I understand the iterator and finding of ID's part of this class if
> it is to hold a list of KSyncEntries that need to be navigated. What
> I don't understand is what all the file loading and saving and
> filename setting is doing here. A set like: PrepareToSync ()(ask the
> user to press the hotsync button and prepare connections, etc.),
> GetData() (create the nessesairy KSyncEntries and fill the KSyncee
> object with them) and a SyncFinished() to indicate that the object
> can now further process the result of the sync, either by storing it
> in some local file or by sending it to a device, or... However, I can
> imagine it would be easier (as Holger Freyther has suggested) to
> return a list of modifications to be made to the respective KSyncee
> objects. If they want to rewrite an entire file, they can easily
> modify their own internal set of KsyncEntries using a
> modificationlist, while systems that only need to propagate
> modifications (such as a palm-interface or some other system where an
> API is provided for adding/modifying/removing entries) only need to
> process this modificationslist.

The file functions are there, because the KSyncee objects have to get 
the data from somewhere. To load it from a file was the most easy 
solution, because all the code for that already exists. Of course it 
would also be possible to pass QStrings or other objects. But that's 
not so important.

The important thing is that libksync is able to synchronize to sets of 
data, reardless where the data comes from. I also think that libksync 
should not contain any functions to control the flow of the 
synchronisation (like the PrepareToSync()) method. It should just make 
sure that two given sets of data are in sync after it has finished. 
When this happens and how the data is transported is the job of 
KitchenSync and its konnector plugins.

> I think that each Konnector should be able to provide a
> configurationdialog where things like filenames can be set. No need
> to clutter the object interface with that, right?

You need to get the data into the KSyncEntry objects. Perhaps it's 
better to not do that via files, I'm not sure. Currently it works well 
the way it is.

> I think a good setup would be to separate the KSyncee class, to get
> the following classes:
> KSyncEntry	would stay the same
> KSyncList	would contain a list of KSyncEntries and provide the means
> 		to navigate it (now implemented in KSyncee)

What's wrong with KSyncee? Don't forget that you need to also store the 
information about the state of the synced entries (what KSyncee 
currently does in KConfig files).

> Konnector	a class that would provide an interface for libksync to
> talk to: -methods like PrepareToSync(), GetData() and SyncFinished()

I don't think that libksync should be dependent on libkonnector. It's 
te job of KitchenSync to provide the flow of control and data.

> -methods to provide the UI elements needed for configuration of this
> Konnector

Yes.

> 		-methods that give information about this connector, like the
> 		name and the datatypes it supports.

Yes.

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