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

List:       kde-pim
Subject:    [Kde-pim] Some Kitchensync questions
From:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2002-09-18 13:03:03
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,
Yesterday night I took a quick look at the kitchensync sources to find out how 
kpilot might use it or how kpilot might need to be changed. Please forgive me 
if some questions might  be obvious or stupid, but I this is my first look at 
kitchensync/ksync, and I didn't have too much time. Just give me a hint on 
where to look. Additionally, it was very late at night, so my brain wasn't 
working properly any more ;-)) 

My questions will of course be from a Palm/handheld syncing view, so they are 
quite specific concerning the current functionality of the conduits. I 
wouldn't like switching to something that - in theory - has a better and 
cleaner architecture, but for the next few years will provide less features 
than we currently have.


1) Do I understand it right from the ksync proposal on pim.kde.org that 
kitchensync is the application that does all the communication with the 
"devices" (korganizer, palm, opie, kabc, local files etc.), while ksync is 
just the abstract library with the sync algorithm framework?

2) Do we have to ditch KPilot completely? So once again, once something in 
kpilot seems to get stable, the underlying infrastructure changes, and 
everything has to be completely rewritten from scratch.... That thought is 
not very comforting to me, no matter how big the advantages of a unified sync 
machinery seems.

3a) How can one sync the palm where you also have the backup record available, 
so you possibly know how the record looked like (on the pc and the palm side) 
after the previous sync

3b) How can one achieve a "smart merge", i.e. from the backup record the 
fields which have changed on the handheld and the pc are determined, and the 
fields are merged, instead of copying the whole record over.

4) How can one use plugins that just copy something to the device and don't 
need any record-based sync and conflict resolution (e.g. using libmal to copy 
the AvantGo content to the palm).

5) How about responsiveness of the front end? I realized there are no 
QTimer::singleShot to let qt process the queue between syncing two records. 
Or did I miss something?

6) How can one do the sync when you only know the changed records on one side, 
but not those that stayed the same? Especially when working with serial 
devices, minimizing the traffic is of very high priority, so I don't think we 
should always transfer the whole calendar/todo/addressbook database from and 
to the handheld (On windows to my surprise the sync of these needs only about 
3 seconds. We have to compete with that ...).

7) What if the device (i.e. Palm) does not support timestamps in any form for 
the records?

8) How can one achieve archived records (i.e. marked as quasi-deleted from the 
palm and deleted after the sync, but they exist locally on the pc side. They 
are NO LONGER synced to the device. As an example take past events. You don't 
need them on the handheld any longer, but of course you don't want to loose 
the history on the PC.).

9) What if one side (handheld) does not support all features the pc side 
supports? I.e. the palm only has 5 phone/email fields, while you can have 
many more on the pc. The two addressbook items should still correspond and 
even be equal, although one side has less information available.

10) Is there a daemon or does the whole app have to be in memory? (Sorry if 
this should be obvious, it was very late when I looked through the code and 
wrote down these questions)

11) Is it possible to sync a list of todos where the order of the entries is 
important? (Needed for the Project Manager conduits). I realize that 
korganizer disregards the order of the todos currently, but other 
applications might use the ics file corretly (i.e. preserving the order)


Thanks,
Reinhold

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9iHmMTqjEwhXvPN0RAoXUAJ49vxXnadV/N7c4tZe+p7Dv7hpGTwCeJr8k
fnsMrXtuQC5WiDsK7i/3JZ4=
=qS6f
-----END PGP SIGNATURE-----

_______________________________________________
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]