[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:       Andre Somers <a.t.somers () student ! utwente ! nl>
Date:       2002-01-25 12:09:55
[Download RAW message or body]

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

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

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

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)
Konnector	a class that would provide an interface for libksync to talk to:
		-methods like PrepareToSync(), GetData() and SyncFinished()
		-methods to provide the UI elements needed for configuration of 
		this Konnector
		-methods that give information about this connector, like the
		name and the datatypes it supports.


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