Re: RFC libksync

Am Wednesday 22 May 2002 23:36 schrieb Cornelius Schumacher:
> 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.
I figured that ;) Remember my private mail that I know understand the reason 
for KSyncee ;)
>
> > 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?
I can imagine two modes.
First Mode:
You sync once or the first time. For example Opie with KDE. You've uids like 
-12345667 and KORG-1254646.65. ids doesn't mean anything you need to put them 
into relations. This could be done by intelligent merging ;) But when adding 
these entries you would want to assign new ids (if they start with Konnector- 
).
Currently I append a Konnector- to the uid and then assign a new id.
2nd Mode:
You once synced and have all the uid mapping in place -1234567 maps to 
KORG-234567.76 so you can collect metadata. When you can rely on meta 
informations you can easily see what was changed (added, removed, modified ). 
To find modified entries is the responsibility of a Konnector and the 
ManipulatorPart.
This is MetaMode for me. You can rely on the ids ;)
>
> > the included informatins for meta Informations
>
> What exactly is that?
currently I save two copies of the files. One in the OpieKonnector meta dir 
and one in the manipulator part metadir. Then I load both and search for meta 
informations. A list of ids would be enough but I've currently complete 
KCal::Inciedences.
>
> > 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.
no from one KSyncEntry to another but see above
>
> > 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.
It could support it
>
> > 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.
ok you would have to introduce a hash to find modified. It pretty much depends 
if revision or last modified is accurate. Therefore I believe that 
metainformation gathering is in the responsibility of the actual user that 
fills the KSyncee with KSyncEntries et al
>
> > 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.
When the consumer/user fills it out we can save time and hassle from the 
actual syncing code. And the user of a KSyncee and KSyncEntry probably know 
best about it. I hope you agree. 
BTW: I believe that the whole discussion past the point of getting useful ;)
>
> > 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.
hmm not decision yet
>
> > 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.
In cases of Opie uids you may alter it. Group scheduling isn't a problem. 
Could you explain it a bit more.
>
> > It should return SyncReturn which has place for synced
> > KSyncee, and two not synced KSyncees
>
> How can you have unsynced entries after syncing?
If you've a sync mode where not to replaceEntries ;). This could be useful in 
a konsole app where you don't want replacement.
>
> > 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().
But the API doesn't force to have an KSyncee as parent and even if it's 0.
>
> > 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.
getting asynchrnous synchronus without using a different code/syncing 
algorithm. But yes get syncing work synchronus first.
>
> > 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.
ok I will look at it again. Ok it's far too limited to fullfill my goal. But 
yes it can be changed ;)
>
> > 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.
True. But we should support it right from the beginning or at least have it in 
mind. At least this is what I believe is best. KitchenSync got some 
shortcomings because of unimplemented hooks I indirectly provided.
>
> > 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 ;-)
see above.
Add added when matching isn't working. deconflict modified if modified in the 
other set. delete if not modified, deconflict if modifief
>
> > 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.
Yes we shouldn't even try to sync them. We shouldn't even allow inserting a 
KSYNC::FooBarEntry into a KSYNC::BarFooSyncee ;)

> > 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.
hmm
>
> > 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.
kewl this benefits KitchenSync ;)
>
> > 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.
But please only past the LT and if you come to the LT we can start doing a 
'complete' KSyncee/KSyncEntry replacement ;)

regards Holger

PS: Yes the discussion is very useful by now
_______________________________________________
kde-pim mailing list
kde-pim@xxxxxxxxxxxx
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/