>>>>> "DD" == Dinesh Dutt <[EMAIL PROTECTED]> writes:
DD> Thomas E Deweese writes:
>> >>>>> "RB" == Rob Browning <[EMAIL PROTECTED]> writes: current
>> thinking is that along with the Pilot record-id it should track
>> which fields from BBDB went to what fields in Pilot. This would
>> allow much more targeted and correct updates.
DD> Why do you want to do this ? If I add a new record from BBDB to
DD> the pilot and subsequently modify the record in pilot, I'd like
DD> BBDB to have the updated information when I sync the next
DD> time. Could you please clarify ?
Yes, the real problem is say when you delete a field from the
Pilot (say a phone number you just tried and got a disconnected
messsage for). The question then arises how do you know which field
in BBDB should be deleted? This may sound simple but is actually
quite tricky because something that looks like a phone number would be
mapped to a BBDB phone number, but 'other' things will be mapped to a
'notes' field.
Without knowing exactly what the original BBDB->Pilot mapping was
it is hard to know what BBDB field to clean up. This is _probably_
possible to do, just fairly complicated and prone to breakage (you
need to 'test' fields in BBDB to see if they would map the the field
under consideration in the Palm record). Remembering, exactly what
fields were mapped where makes this process much simpler, and the code
much less fragile (ignoring for a second 'slow sync' issues).
>> So extending this a little bit, allow multiple pilot record-id's
>> and for each record-id track which bbdb-fields went to which
>> pilot-fields in each record, so name and company might always go to
>> both, but Home (phone and address) went to one record and Work goes
>> to the other. This 'invisible' linkage of certain fields might
>> cause some problems. Consider a person who consults at multiple
>> companies, you might want the Company name different for each of
>> the Pilot Records but every time you synced it would overwrite the
>> other Company :(.
DD> A simple way to do this is to mimic the Pilot's AB. Have a unique
DD> id associated with each BBDB record (optionally associate each
DD> record with a category) and each BBDB record with a unique id goes
DD> to its own Pilot record and store the Pilot ID and BBDB ID
DD> someplace (it could be in the BBDB itself).
Ahh, but we no longer have a 1:1 mapping we have a 1:N mapping.
Various parts of one BBDB record are now get mapped in to several
Pilot Records (the split part). Now tracking which fields belong to
what starts getting really complicated without remembering what
mapping was used.
>> The other real trick is knowing when it would be appropriate to do
>> the split and when not (my current feeling is when there is more
>> than one address). You could also have it be directed by another
>> BBDB field but then you are starting to accumulate junk in the BBDB
>> record.
DD> This maybe more complicated than at first sight since different
DD> folks have different ideas of when they'd like to split a record.
Of course this is the main issue. My first suggestion is
automatic and solves the biggest BBDB<->Pilot issue namely one address
per record on the Pilot. It doesn't however deal 'complex' people
cases. The second case where the user provides the splitting info
takes care of this but would be a (mostly) manual process. :(
--
Thomas DeWeese
[EMAIL PROTECTED]
"The only difference between theory and practice is
that in theory there isn't any." -- unknown
_______________________________________________
bbdb-info mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/bbdb-info
