> Ronan:
>> Realistically speaking, you need 2.2 for syncing with anything more
>> than a trivial Pilot addressbook, for the simple reason that 2.2
>> allows you to have multiple records with the same name (just like
>> the Pilot) where as 2.00.06 requires you to do some heuristic
>> merging/splitting of records to sync up.
>>>>> "PCP" == Patrick Campbell-Preston <[EMAIL PROTECTED]> writes:
PCP> Fair enough, but this is *not* what I want to do. I want to use
PCP> exactly that subset of the Palm addressbook's functionality which
PCP> matches the functionality of 'classic' BBDB, and sync
PCP> accordingly. The BBDB rules: I do not want it to emulate the
PCP> Palm, I just want to be able to carry its contents around on the
PCP> Palm, occasionally update them there, and sync back. Reliably.
The Reliably bit is the problem. While the palm does allow
"duplicate records" this is not the main reason I went and added
support under bbdb for duplicate records. The reason is that when
synching you will encounter situations where a single record has been
modified both in bbdb and on the palm. When the sync happens which
set of modifications do I take? Either way I'm throwing away
information that someone has taken the time to add.
The normal solution is to replicate the record on both sides, this
of course generates a duplicate record (a convienence function
bbdb-show-duplicates makes the merge processes fairly painless). I
understand that this is not ideal (where ideal is read your mind and
figure out which of the two phone numbers is now "the right one") but
this is only done when the only other choice is to randomly throw away
information.
Also, what would you want done if you entered a new record on the
palm which is duplicate of a record already in your bbdb?
I hope this helps to clarify why duplicate records are needed when
supporting bidirectional sync operations.
_______________________________________________
bbdb-info mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/bbdb-info
