[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:       Holger Freyther <freyther () gmx ! net>
Date:       2002-06-11 6:54:47
[Download RAW message or body]

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

Am Monday 10 June 2002 18:14 schrieb Reinhold Kainhofer:
> 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.
Basicly you can/need have 2-4 Entries.
2 Entries if you can determine the differences by a modified flag ( which is 
bad )
4 Entries to have a full  view to what was changed.

Basicly when conflict resolving you want to have something like KDEs (kio ) 
RenameDialog. It has a button bar and plugin support so if you copy one png 
to another you get prompted and will see two pngs with some meta data. So the 
data worth viewing needs to be represented in a useful way.
We could pass a QWidget from a KSyncEntry but this would limit conflict 
resolving to GUI. We could exchange designer xmls but this would be huge 
todo.
When we got some data to make a widget we can show left what was on the Palm 
for Example and on the right what was on the PC. Ideally we should only show 
which fields are conflicting.
3rd we should maybe have a way to have the possibility to create a new set. 
4th a conflict should only exist if the same field on both sides was modified.
>
>
>
>
> 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)
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

2nd is quite heavy for KitchenSync which targets to sync everything with 
everything.
I had a small patch for libkcal where you could add as many ids as you wanted.  
But we decided this would be the wrong way.
I created a small 'database' ( ondisk format is badly broken by concept 
(KConfig based) ). Where you can add a set of two ids per a category ( todo, 
abook, calendar ... ).

> 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
this is how it should be. KItchenSync API was determined to change so the 
current SyncAPI is a hack.
> 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.
yes this is what I saw in syncing code of addressbook and calendar too. with 
KSyncee and KSyncEntry thanks to Cornelius we will have only one 
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.

> 6)
we would wirte it back and then save the set ids so we can update the MAP to 
not get huge

regards Holger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9BZ67GckbdURWU2oRAm4JAJ9wBjLnxm8PW8AhLBik+zGgbZaGoACeMD9m
BaUD6CKCF2xRGLvB5tN9yOg=
=Bv8M
-----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]