>>>>> "RW" == Ronan Waide <[EMAIL PROTECTED]> writes:
RW> On July 5, [EMAIL PROTECTED] said:
>> Do people have opinions on what they think the 'ideal' system
>> would be? For what it's worth, I'm not overly attached to my conduit
RW> - My BBDB runs constantly from when I log in to when I log out. Thus
RW> it's not feasible for me to use something other than emacs to write
RW> to the bbdb, because then I'll have conflicts between on-disk and
RW> in-memory data.
Same here.
RW> - Bringing these two points together led me to my current belief
RW> that the best way to manage this is to provide the BBDB with a
RW> generic merge/sync framework - which I've done an amount of work
RW> on - and then allow whatever app you want to talk to that,
RW> probably through gnuclient. This probably requires you to use an
RW> independant gnuclient distro since the last time I checked,
RW> emacsclient as distributed with GNUmacs was restricted to opening
RW> files only. gnuclient will allow you to remotely run arbitrary
RW> chunks of lisp, which is ideal for syncing.
RW> The current AddressBook conduit on PilotManager allows you to
RW> choose one of several output formats. Perhaps a gnuclient option
RW> could be added to get it to talk to bbdb and do record matching.
My conduit let's you provide a script to execute prior to reading
the bbdb database (which in my case uses gnuclient to do a
'bbdb-save') and a script to run after rewriting the bbdb (in my case
does a gnuclient 'bbdb-revert-buffer'). This way there are no issues
(well only a very small transient one if you modify your bbdb while
the sync of your bbdb is happening).
This is a simple inversion of your thinking.
>> [using a unified bbdb merge engine] is an attractive idea, thoughts
>> on how to avoid having to do a full sync (transfer the whole
>> address book from the palm) every time to perform the merge? How
>> is record matching being accomplished (given that names/email
>> addresses are no longer unique :).
RW> Yep: You need to do one full sync to get everything in line, and part
RW> of that full sync is to store the pilot record IDs in the BBDB. For
RW> records that need to be split, the code generates a fake pilot ID and
RW> adds that to the record in question so your ID field might have
RW> multiple ID's in it. Or you can manually split the record and have
RW> each with a unique ID.
Hmm, so the intent is to use SyncAB (or something like it) to sync
with an intermediate form which you then sync with BBDB in Emacs. In
essence two syncs (Pilot <-sync 1-> CVS/VCard <-sync 2-> BBDB). This
seems like it would tend to be more problematic than doing the sync in
one step. The only way case where this would not be true is if we
felt that each of 'sync 1' _and_ 'sync 2' were going to be used far
more widely than just for BBDB<->Pilot. This would help to ensure
that the individual parts were significantly more robust than the
single link replacement.
Incidentally doesn't this really involve three syncs to get
everything properly synchronized?
BBDB <- sync 1 -> VCard
VCard <- sync 2 -> Pilot
BBDB <- sync 3 -> VCard
If you omit sync 1 then changes in BBDB won't get viewed in
Pilot until the next sync. If you omit sync 3 changes in the Pilot
won't get seen in BBDB until the next sync.
RW> I did consider rewriting the Pilot addressbook to be more like the
RW> BBDB...
Well even if you did this you would still have the sync issues
it's just that the sync/merge code would be more straight forward
since little or no translation would need to take place.
--
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
