RFC libksync

Ok,
the whole topic seems to be such controversal.
My KSyncEntry is incomplete and KSyncs KSyncEntry is more incomplete
KSyncAPI is much more convienant because I've no real API for syncing yet.

The distinction between KSyncee and KSyncEntry is cleaner and favorable.
I agree on the general deisgn of KSyncee and KSyncEntry. When I first looked 
at it Bookmark syncing didn't show the reason for existance of KSyncee. But 
it's clear and desirable to have.

Still KSyncee and KSyncEntry lacks things present in KitchenSync KSyncEntry
This includes 
the setting of syncmode
the included informatins for meta Informations
the id map
a QString type()
I hope I didn't forget anything.

What KSyncee shouldn't do is loading ( it's rather FileSystem oriented but for 
convience it should be ok )
saving. Gathering of metainformations is not KSyncees goal IMHO. It should not 
try to.
KSyncee should have a sync virtual QString type()const. It should have the id 
mapping and meta informations KSyncee* modified(), KSyncee* removed(), 
KSyncee* added(). KSyncee should have parents so we can assure auto deletion 
a la QObject.

KSyncEntry should get the above mentioned functions.
KSyncer should only return one KSyncee when synced. This is IMHO more logical. 
it should include all necessary metainformations( id replacement )
It should return SyncReturn which has place for synced KSyncee, and two not 
synced KSyncees
KSyncEntry should always have a KSyncee parent and a KSyncee *parent() method. 
So when syncing you can check for mode, metainformations.

The syncing should be available in two modes async and sync. Sync could be 
done via the qt_enter_modal hack....

Merging should be possible when enabled.
Coming to conflict resolving. We should provide value based conflict resolving 
for merging and replacing. Value based means if a KSyncEntry is built around 
KCal::Event it should be able to display the properties.
To be able to do this. The sync code should throw exceptions... No real 
exceptions but it could call an installed handler for conflict resolving. 
There should be 3 things a KSyncEntry supports. First a Widget for the view 
of the Entry, 2nd a XML (designer file ) of the widget (for konsole 
operations whatever ) and a general widget for edititng and entering an 
Entry. The last widget could be used for entering a third. The widget gets 
reparented. Let's say the description and summary conflict it would only 
display the fields relevant and give an input widget. Now the handler returns 
sync code will look at the return and either replace or give the 3rd widget 
back to the sync code. Which can the decide.


Coming to syncing. There should be two ways. Only adding, matching, merging 
conflict resolving and a meta sync mode.

Then it should be possible to install SyncHandlers todo the actual syncing.
We shouldn't even try to sync across two differen types of KSyncee right?

Then the Calendar should be Incidence based it should be split up into Events, 
Todos, Journal.

This is more or less what I want from a complete sync lib. I hope that we can 
agree on that.
If we agree. You may rename all the files.
I will do the namespaces
I will migrate to KSyncee and KSyncEntry and send you a patch for my changes
I will migrate the rest and we can modify the rest of KSYNC::SyncManager ;)

Is this an offer? Can we agree on that?

regards Holger

PS: This will be done past the LinuxTag
_______________________________________________
kde-pim mailing list
kde-pim@xxxxxxxxxxxx
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/