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

List:       kde-pim
Subject:    Re: KitchenSync vs. KPilot (was: Re: [Kde-pim] first release of kio_mobile)
From:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2002-06-11 10:23:54
[Download RAW message or body]

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

On Tuesday 11 June 2002 08:54, Holger Freyther wrote:
> > 1) from the PC side (addressbook, vcal) create a map Palm RecordID -> PC
> > entry ID to speed up the searches later on (the Palm recordId is saved in
> > the abook and the cal)
>
> why setModified and palm id is bad in libkcal and libkabc:
> 1. you make files a bit larger as they should be
> 2. you make addressbook and calendar only sync with one pda

Yes, both arguemtns are true. However, if we don't store some kind of 
identification code, there is no way to easily determine which items go 
together except for comparing each one to every (remaining) record on the 
other side. And this is just too expensive ( n (n-1)/2 compared to 
practically no effort)...

The problem with not having a modified flag is that you then have to compare 
each record on the PC side to the record of the backup database, which again 
means an effort of n compared to just checking a modified flag.

Nr. 2 is cured somehow by allowing a "First sync" which ignores the palm ids 
and just compares all the items to each other. But you are right, there might 
be better ideas. Especially, storing the map RecordID<=>PCEntry id in an 
external database that is only used by the sync application (be it KPilot or 
Kitchensync) might give us greater flexibility, but removes portability (e.g. 
copying the whole calendar file to a different computer does not preserve the 
map there.

> 4th a conflict should only exist if the same field on both sides was
> modified.

Yes, that's how the addressbook conduit will work. 

> synchronisation code ( can be replaced on runtime ). So you'll only need to
> supply the modified, added and removed lists from both sides. Where the
> KPilot-Konnector only needs to care for the KPilot and not KDE.

The problem with this is, there is no easy way to find out which items were 
changed (especially if you switched PCs, because you sync with two different 
pcs). All you can do is compare all the items to their counterparts, so 
merging them is not much more effort. 

Reinhold

- -- 
- ------------------------------------------------------------------
DI Reinhold Kainhofer, Graz, Austria
email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Mathematics Department, Technical University of Graz
 * Theoretical Physics Department, University of Graz
- ------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Bc+6TqjEwhXvPN0RAiWhAKDZixumeK14xxHUmiZ/CHaVx/iOLgCgoNQ/
RWX6D0+7nNPHCqqMxg1/Q+M=
=D7am
-----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]