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

List:       kde-pim
Subject:    Re: [Kitchensync] Re: [Kde-pim] Some questions about KitchenSync
From:       Holger Freyther <freyther () gmx ! net>
Date:       2002-05-22 16:17:47
[Download RAW message or body]


> Ok, if it's fine with you I will do it.
but please do it past the linux tag and ask david so we can keep cvs history.
>
> > > > > The konnector interface has functions for e.g. setting IP
> > > > > addresses. This is a special attribute for network like
> > > > > connections, but doesn't make sense for many other connections,
> > > > > e.g. the connection to a mobile phone over a serial connection.
> > > > > Wouldn't it be better to hide such implementation specific details
> > > > > in the implementation and not expose them in the interface?
> > > >
> > > > Sometimes you need to set the IP Address. The Kapabilities class is
> > > > there to propagate the abilities. If your konnector plugin doesn't
> > > > need a network connection it can set the bitfields to the appropiate
> > > > actions.
> > >
> > > But this is not an object-oriented design. If a Konnector
> > > implementation needs IP addresses it should define them internally and
> > > e.g. provide a configuration widget to set them, which can be used by
> > > KitchenSync in a generic way.
> >
> > providing a Widget isn't OO either. What about if I don't want a gui? How
> > should I configure a konnector?
>
> Providing a widget is OO. If you want to support GUI and text mode you have
> to use an additional abstraction level, but do you really want to do this?
That's arguable. How is a Widget more OO than a set of Kapabilities? 
An abstraction level would be the Kapabilities. A Konnector can support a set 
of fixed functions and extend it. Any Consumer can configure the konnector 
the way they want it.
Hm if I remember it correctly your were the person aksing why there is a GUI 
needed. Actually I like Kapabilities because they give the possibility to 
configure  a konnector in a typesafe(!) way. Kapabilities are giving a 
possibility to configure any Konnector in a type safe way.
>
> An easy way to configure specific connectors would be when the code
> creating the Konnector objects would do it. It knows the subclass so it can
> do whatever specific actions are required. Shouldn't the plugins of
> KitchenSync which are shown in the GUI do this?
No. The point of class Konnector is to have a generic way of dealing with 
KonnectorPlugins. This includes configuration. Ideally we write one gui make 
it stable and then only write konnectors for every new device popping up. You 
argue for no abstractions between one special konnector and the gui. Or do I 
miss the point?

>
> > > By the way, while looking at the source of libkonnector I got the
> > > impression that the Konnector class is used in the wrong way. It is
> > > managing
> > > KonnectorPlugin objects rather than defining an interface. Wouldn't it
> > > be better to rename it to KonnectorManager and KonnectorPlugin to
> > > Konnector (or KonnectorBase) and remove all the KonnectorPlugin
> > > interface functions from KonnectorManager?
>
> No opinion?
Sorry forgot about it :(
KonnectorManager would be more apropriate.
>
> > > > > There is no code in KitchenSync to perform the actual syncing, i.e.
> > > > > making to sets of data equivalent by copying updated entries,
> > > > > removing obsolete entries and resolving conflicts. Is this right or
> > > > > did I miss something?
> > > >
> > > > true. Over the weekend I implemented gathering of meta informations.
> > > > I also implemented the first bits of syncing. Though this should be
> > > > considered a hack. It's synchronus and every SyncPlugin needs to
> > > > implement its own syncing. This could be seen as drawback. Where
> > > > KSync uses KSyncee and KSyncEntry you can have one sync procedure.
> > > > But when there is a set of data which needs a different way of
> > > > syncing it's not possible with KSync API. With my KitchenSync API
> > > > there is the possibility of code duplication which could be solved by
> > > > making a template.
> > >
> > > I have now implemented AddressBook syncing in libksync. If there is a
> > > way of syncing which is not possible with the KSync API, we can add it,
> > > where's the problem. Duplicating the syncing code is a very bad idea,
> > > because this kind of code tends to be a horror to maintain.
> >
> > The problem is that equals and findEntry tend to be not as useful as it
> > seams.
>
> These are functions which can be overwritten for specific data types (i.e.
> subclasses of KSyncee). For an id based syncing algorithm these functions
> are required.
And most PIM Data types are UID oriented. findEntry by uid is ok. equals can 
be ok as well.
equals is arguable but ok. Cause it gives us the possibility to do what we 
want.
>
> > How is your code able to remove entries or how to detect it?
>
> It can use the log which is written at each syncing. If an entry has been
> removed it's missing in the data set, but it's still there in the log. This
> isn't implemented yet, but it shouldn't be a big problem to add that.
My way is a bit different. KAlendarSyncEntry has functions for added(), 
modified() and removed() items. These fields are only relevant when not first 
syncing and in MetaSync mode. But read below for more.
>
> > How is
> > it able to do a clever merging in replaceEntry?
>
> replaceEntry is a helper function for replacing one entry by another. It is
> not intended to do merging of entries.
It should ;)
>
> > The code or KSync API
> > completely lacks that.
>
> There is no support for merging individual entries, but this should be part
> of conflict resolving. There is no way to do this without user interaction,
> because if you have two entries (e.g. contacts) which both have changed,
> but in different fields (e.g. one has a changed email, the other has a
> changed phone number) you can't find out which entry has the more current
> field, because fields don't have timestamp or lastmodified information.
True but if in not the same field is changed in two entries you can merge 
them. If changes are conflicting deconflict
>
> You might be able to suggest a possible merge, when you have stored the
> value of all fields of the previous sync and can compare to see, if it has
> changed. But that's not safe because a field could have been changed and
> then changed back to the original value, and it would require to store the
> complete data being synced.
This was one reason for me not saving meta data. If using a log you can see 
what was changed. You can not see what was modified. There you would have to 
keep a set of meta data. Either last modified or revision. But both fields 
are not accurate on all sides. So filling metadat is the responsibility of a 
Konnector and a 2nd side the ManipulatorPart. You could create a way to 
generic store informations for a specefic uid. But the word generic is the 
key.
While Qtopia got at least a revision for entries Opie lacks it. So you need a 
common demonator.
>
> > Merging and syncing is different. I'm able to write
> > an App in one day which is capable of merging two sets of data. That is
> > where your KSync API is good for. I'm dealing with KitchenSync for
> > roughly 4 month now.
>
> Come on, you are not the only one thinking about syncing and writing
> syncing code.
Could it be that you're fighting a personal war? It seems that nobody is 
really interested in syncing or lacks the time to get involved. I told you in 
private mail that KitchenSync is far from perfect. I don't know why you did 
not call me to solve that or joined #kde or #opie.de to talk to me. I'm not 
bitching about libkcal here.....
But that's my point of view.
>
> > I know that some parts of KitchenSync aren't good enough and
> > need rethinking and a rewrite and or adjustment.
>
> The same is true for libksync. My objection just is that you duplicate the
> functionality of libksync. Please try to use it before you write the same
> thing again. If there is something missing we can add it, but there is
> really no need to write this thing once again.
Ok I will write a separate email with libksync in the subject.
>
> > For once KSyncAPI is completely synchron. This will block the ui.
>
> We can make the interface asychronous, that's not the problem, but I would
> think that the first step is to get the syncing itself right and then deal
> with UI issues.
:) then deal with design issues. Same is true for KitchenSync.
>
> > When syncing with other than desktops the ids mostly don't match. For
> > example Qtopia/Opie uses a negative int.
>
> We can use a map which translates the ids.
A map is enough for KSync but not for KitchenSync. For example you can have a 
KAlendarSyncEntry( we will change the name) and it includes events and todos. 
Which can possible have the same id. so a map is not sufficent. Actually the 
same applies to KSync but read the other email.
>
> > The idea of syncing is too match
> > the same data not ids...
>
> But you have to identify what the same data is. That's difficult and often
> impossible if the data changes. That's the reason why most systems have
> ids. Syncing without ids is difficult and not safe. Take for example a
> phone book entry "Hans Wurst 12345", is it the same as "Hans Meier 12345"
> or "Hans Wurst 6789"? You can't tell. Hans Meier could be the same after
> his marriage or it could be the son using the same phone, "Hans Wurst 6789"
> could be the same entry with a new phone number or it could be a second
> phone.
Hopefully these informations a stored the OO way in a dedicated field. 
Intelligent matching is key. But this only applies to FirstSync and not 
MetaSyncing if you can not trust uids for some reasons( uids are most of the 
times host unique and no I don't want GUIDs ). 
For a really decent syncing matching is a feature which should be good and 
configurable
>
> > > By the way, you don't have to CC me. I'm subscribed to kde-pim ;-)
> >
> > by the way please write to kitchensync@mail.kde.org
>
> It would have been nice to announce the creation of this list. But do we
> really need an additional mailing list for that? What's wrong with kde-pim?
> Kitchensync definitely belongs to kdepim.
there was nothing to announce. Personally I don't want to annoy kdepim with 
user mails.

regards Holger
PS: another mail will follow
_______________________________________________
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]