[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-24 14:31:13
[Download RAW message or body]

On Thursday 24 January 2002 11:07, Cuendet JeanEric wrote:
> > KitchenSync could imho be a central place connecting 'things',
> > everything from a palm to kmail, to .Net's MyFavoriteSites(?) to
> > Konqueror's bookmark manager. These connections should come
> > as plugins,
>
> That's a VERY good idea. I think that there should be connectors that
> Input/Output common types of data: CalendarEntry, AdressbookEntry, Mail,
> NotesEntry, etc...

Ok, let's have connector (or maybe: konnector, in order to stay in KDE style) 
be the 'plugin'  or ' conduit' in Palm-speak one uses to have something 
synchonize using KitchenSync.
>
> This could lead to a great architecture where each plugin would be able to
> speak to each other in the following way for example:
As far as I'm aware, there still doesn't really exsist an architecture on how 
this KitchenSync and the interaction with the Konnectors should work. In 
order to design one, I think we need to start by looking at how the syncing 
between two or more objects works. Only if we can come up with such a sceme, 
I think you can make the step into designing the framework on an 
object/interface level.

So... how *does* one sync objects? Let's start with a simple case, and work 
to more complex cases afterwards. I'll try to make a start, correct me if I'm 
wrong.

=====
Case 1: the syncing of two objects
Say you want to make your Palm (I use this as an example, this is most 
familiar to me) sync it's adresses against Kabc. I will use the general term 
'device' for the objects who's data should be synchonized, in this case the 
Palm and Kabc. The syncingprocess would look like this:

  1) Get a list of additions, modifications and deletions since the last sync
  2) Add all additions to the other device
  3) Scan list of modifications and deletions for records that are modified 
on both devices, and resolve these problems (this may be resoved using a 
setting to prefer the Palm in such cases, or by displaying a dialog to the 
user and have him resove the conflict)
  4) Commit the modified records to the respective devices and execute the 
deletions.

ad 1. In order to be able to get this list, a Konnector must be able to know 
which records are modified. This seems trivial, but can be difficult if for 
instance the device you're trying to sync with doesn't support the notion of 
a modificationdate or -flag.  If it doesn't, I'd say the Konnector should 
make arrangements itself in order to keep track.
ad 2. This looks straitforward to me. Any problems to be expected here? (see 
also ad. 3, this may be relevant here also if ID's need to be created)
ad 3. Scanning this list presupposes that there is some unique ID wich 
Kitchensync can use to regonize identical records. Again, not all devices may 
support this natively. Furthermore, this ID must be shared between the 
devices or at least between the Konnectors. Not all devices will support 
choosing a free ID for new records. In this case, the Konnector will have to 
provide one.
Conflictresolving is an important part of the syncing I think. I'm not sure 
where this should be handled. The problem is that we have two (let's stick to 
two for simplicity now) konnectors involved, yet we need a *common* 
conflictresolving mechanism. I think the most logical place would be 
KitchenSync itself. I will return to this subject later on.
ad 4. This should be pretty straitforward.

That concludes this simple case, I think. 
=====
In the case above, I have skipped over a few things that are important also. 
The first problem is that KitchenSync needs to know about what Konnectors are 
acting on the same datatype. For instance, the example in Case 1 is about the 
' Addresses' or 'Contacts' datatype. There are many more datatypes imaginable 
that can be synced. KitchenSync should abstract the syncing process from the 
datatypes itself and be able to sync any type of data. This suggests that a) 
the Konnectors need to register to KitchenSync what datatype(s) they support, 
and b) data needs to be 'packaged' in an object that KitchenSync can handle 
(I believe we agreed to call these KSyncEntries). So, we have a general 
KSyncEntry that must be subclassed per datatype (for instance 
KAdresSyncEntry) and may in it's turn be subclassed by each Konnector to suit 
it's private needs, for instance for reading and writing the data to it's 
backend format. So, c) a common subtype of KSyncEntry is nessecairy however 
in order to be able to exchange the data between the different Konnectors.

To come back to the resolving of conflicts: I would like to propose to 
implement this in KitchenSync. If all Konnectors register themselves with 
KitchenSync, KitchenSync can create a configuration for the resolving of 
conflicts per datatype, giving the following options: let one of the the 
registered Konnectors prevail, or display a dialog per conflict to have the 
user choose. A nice feature would be the opportunity for a Konnector to 
register a small viewerwidget for the datatype, that KitchenSync can present 
to the user for the conflicting records. This would allow the user to make an 
educated choice in resolving the conflict, but it should (in my view) not be 
nessecairy to register such a viewer.

Other cases:
Where I tried to analyse the simple case of two devices trying to sync their 
data, there are other cases we need to considder before deciding on an 
interface for KitchenSync, and the KSyncEntry and the KSynCee forming the 
Konnector (maybe completed with a viewerwidget). These cases are:
1) syncing of two devices (done above)
2) syncing of more than two devices
3) syncing of devices that participate in syncing with more than one object, 
for instance, a Palm you want to sync at home and at your work.
4) how can devices "catch up" with other devices when syncing. For instance, 
say I have a setup where I want to synchonize addresses between my Palm, my 
mobile phone and Kabc. I don't allways connect my phone when syncing, so this 
device may be out of date with the other two. They don't share the same "last 
sync time". 
5) ....?

I think in order to design a good framework and have KitchenSync be a robust 
syncingenvironment that can last for some time, we need to work out these 
(and possibly other) scenario's before deciding on the interfaces and objects 
we need. Only by analysing how a sync works can we know what we need to 
accomplish this.

Finally, some other observations:
-Konnectors may be readonly
-Konnectors may supoort more than one datatype.
-One Konnectortype may be connected several times, for instance a Konnector 
that can syncronize directories on disk or over the network may be set up to 
sync several different directories where each directory may need to be able 
to be synced seperately.
-Some devices may need some user-interaction in order to able to sync (again: 
think about the Palm where you need to press the hotsync button). Therefore, 
Konnectors can't be assumed to be imediatly ready to start syncing if a 
syncing actions is initiated, and so the KSynCee should provide a method for 
this.
-We need to think about how syncingactions are initiated. 

That concludes my thoughts about KitchenSync I had during a boring lecture 
this morning.... :-)


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]