Re: RFC libksync

On Wednesday 22 May 2002 18:51, Holger Freyther wrote:
>
> 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.

The CalendarSyncee is a better example than the BookmarkSyncee if you 
are interested in the concepts of libksync.

> Still KSyncee and KSyncEntry lacks things present in KitchenSync
> KSyncEntry This includes
> the setting of syncmode

What do you mean by syncmode and what different modes should be there?

> the included informatins for meta Informations

What exactly is that?

> the id map

If you mean mapping ids from one KSyncee object to another KSyncee 
object this shouldn't be part of KSyncee, but in an external helper 
class.

> a QString type()

Ok, that's trivial.

> What KSyncee shouldn't do is loading ( it's rather FileSystem
> oriented but for convience it should be ok )

Agreed. But as it's always possible to pass the information via a file, 
this is ok for now, I would say.

> saving. Gathering of metainformations is not KSyncees goal IMHO. It
> should not try to.

I'm not sure we have the same understanding of metainformation. What 
KSyncee saves is the information which entry has been synced and when. 
This is done in a generic way independent of the concrete type of 
KSyncee. As this information directly corresponds to the set of data 
the KSyncee object represents, I think it is the job of KSyncee to save 
this data, but it could also be done externally.

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

Why do you need extra collections of modified, removed and added 
entries? You can as well iterate over a single KSyncee and examine the 
modified/removed/added state entry by entry. But if you have a 
compelling reason to have these functions it should be possible.

> KSyncer should only return one KSyncee when synced. This is IMHO more
> logical.

KSyncer does not return a KSyncee at all when syncing. There is a 
function to sync all registered KSyncees, which makes these KSyncees 
consistent, there is a function to sync all registered to a target 
KSyncee without changing the source KSyncees and there is a function 
syncing one KSyncee to another KSyncee.

> it should include all necessary metainformations( id
> replacement )

You can't replace ids. If an entry has an id, syncing musn't alter it. 
Otherwise things like group scheduling get broken.

> It should return SyncReturn which has place for synced
> KSyncee, and two not synced KSyncees

How can you have unsynced entries after syncing?

> KSyncEntry should always have a KSyncee parent and a KSyncee
> *parent() method.

It does have a parent and a corresponding method. It's called syncee().

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

This is something we should care about when syncing works and I'm sure 
we can find an implementation which doesn't need hacks.

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

Yes.

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

That's the purpose of the KSyncUi interface.

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

Ok, something like that, but it will probably not a very common case 
that two entries change, but in different fields. This should be well 
encapsulated in the deconfliction code, so we an take care of this, 
when the other aspects of syncing are working.

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

Could you please define what you mean with meta sync mode. Ok, I'm 
repeating that, but I'm really not sure that I understand what you mean 
with that term ;-)

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

You mean syncing events with bookmarks? That doesn't make much sense to 
me.

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

These can be synced seperately, but maybe there is also a clever 
implementation how to do this on a more abstract level by using 
Incidence.

> This is more or less what I want from a complete sync lib. I hope
> that we can agree on that.

There are some open questions, but I'm quite sure that we can come to an 
agreement.

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

Ok, let's work toward this goal.

-- 
Cornelius Schumacher <schumacher@xxxxxxx>
_______________________________________________
kde-pim mailing list
kde-pim@xxxxxxxxxxxx
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/