[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-10 16:14:01
[Download RAW message or body]

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

On Monday 10 June 2002 16:58, Holger Freyther wrote:
> Conflict resolving. We should have a generic way of doing this

True, this would reduce code redundancy. However, currently in the conduit 
I've seen we compare and merge the appropriate KCal::XXX and KABC::Addressee 
classes with our own PilotTodoEntry/PilotDateEntry/PilotAddressEntry, which 
are just wrapper classes around the pilot-link functions and data types. I 
guess a generic way of conflict resolving would require to have two (or three 
if you have the backup record from last sync available) records of the same 
type. That would mean a lot of overhead to copy the data from the Pilot*Entry 
instance to another class, compare that class and discard it again... But 
maybe I'm wrong and these extra operations don't matter at all.




Anyway, while rewriting the third conduit (calendar, todo and now the 
addressbook), I realized that all of them have a  *VERY* similar structure 
(to reduce the slow PC <=> Palm traffic). This describes how the addressbook 
conduit will be (and if I find the time, also the calendar conduits):

Preparation:
===========
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)
2) get a list of all record Ids from the palm (needed later on to determine 
which records have been deleted from the palm without the archiving option 
on)


Sync:
=====
3) In a loop (use QTimer::singleShot) get the next modified record from the 
Palm. Add/Update/Delete the according PC record. If new records are added, 
add them to the map from 1). Also add all the synced record ids to a 
QValueList<recordid_t> syncedIDs. If PC side was changed, too, let the user 
decide (either by a default PC/Palm overrides or ask for every item)
4) In a loop go through all entries on the pc side (Palm ID stored in the 
entries!). If the PC side supports a modified flag (e.g. libkcal sets one for 
KPilot, libkabc unfortunately doesn't ), just go through all modified 
entries. If the palm ID has already been synced, skip. Compare the entry with 
the record from the backup database on disk. If it was changed/added on the 
PC, update the palm record.
5) In a loop go through all entries in the backup dabase on disk. If the 
according entry on the PC side does not exist, it was deleted there, so it 
prabably needs to be deleted from the palm, too (if the ID is in syncedIDs, 
we have a problem... But then it shouldn't exist on the palm any more, so no 
real problem) If the corresponding Palm entry does not exist, it was deleted 
there (and the dabase was cleaned up to purge deleted/archived records from 
the palm database), so we also need to remove it from the PC side. 

6) We're finished. Cleanup

Note that in the last step 5) we don't need to care about conflicts, since all 
changed Records should have been synced already. If course, if the previous 
sync was done on a different PC, or either of the database doesn't exist, 
things are a bit different, but the whole structure is the same.

Previous version of the conduits didn't make use of the backup database on the 
PC at all. It makes the sync a little more complex, but allows easy detection 
of what fields of a record changed since the last sync. 

Apart from the fast sync, which I described above, there are also a full sync, 
where the loops go over all records/entries (not just the modified). This is 
needed e.g. if the palm is synced to two PCs, since then the modified flags 
are not correct. And the last possible sync method (and the slowest of all) 
is a first sync, where the Palm Record IDs are completely ignored, and the 
corresponding entries are determined solely by their contents. This might be 
needed if you sync a Palm to a calendar which was previously synced with a 
different palm. I don't know the chance that two records have the same 
recordID, but just in case... 

I don't know how the k(itchen?)sync does the syncs, so I just wanted to give 
you an idea how we do it. I also tried to explain it a little bit in 
kdepim/kpilot/conduits/vcalconduit/vcal-conduitbase.cc (there I didnt' 
describe 1) and 2) and the second part of 5)  ).


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

iD8DBQE9BNBMTqjEwhXvPN0RAs2kAJ9z/2AOFV92kWCkSJFHAp7huusIOgCgu1IS
NZd+DgWYsxNPYOmB79DRDkg=
=3U5u
-----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]