>>>>> "Jack" == Jack Twilley <[EMAIL PROTECTED]> writes:
>>>>> "Thomas" == Thomas E Deweese <[EMAIL PROTECTED]> writes:
Thomas> Incidentally doesn't this really involve three syncs to get
Thomas> everything properly synchronized?
Thomas> BBDB <- sync 1 -> VCard VCard <- sync 2 -> Pilot BBDB <-
Thomas> sync 3 -> VCard
Thomas> If you omit sync 1 then changes in BBDB won't get viewed in
Thomas> Pilot until the next sync. If you omit sync 3 changes in
Thomas> the Pilot won't get seen in BBDB until the next sync.
IMO, this is a very minor issue. You could manage BBDB<->VCard synching
on a regular basis, e.g. it is triggered by a hook each time BBDB saves
or even with cron.
Jack> This is exactly why I'm looking at using LDAP and EUDC as a
Jack> replacement for BBDB. I can have multiple sources sync to the
Jack> LDAP backend, and Emacs via EUDC can continue to give me the
Jack> Big Brother features I find most useful and interesting.
VCard or LDAP is not the point, I think. The BBDB<->Palm synchability
should be useful to as many users as possible. Personally, I synch my
Palm with the shipped synching software. So in order to use a conduit
driven approach I first needed to install the compatible synching
software. On a side note, integrating the synchronization functionality
into BBDB could cause new difficulties, e.g. emacs needed to run
permanently and emacsclient incompatibilities.
I think this problem should be attacked the unix-way: little programs
which do well defined tasks and take files as in/output, for example the
following tasks:
- add addressbook capabilities to BBDB: record id etc
- merge addressbook and BBDB to a BBDB
- transform BBDB to a Addressbook.
These programs could be written in Elisp, Perl or whatever. Important
is that they capture the most complex functionality. Conduits can be
easily designed around these tools for whatever synching platform.
RW> I did consider rewriting the Pilot addressbook to be more like
RW> the BBDB...
Thomas> Well even if you did this you would still have the sync
Thomas> issues it's just that the sync/merge code would be more
Thomas> straight forward since little or no translation would need
Thomas> to take place.
Jack> This to me is a bit of overkill, and it kinda minimizes the
Jack> number of folks who can use the stuff.
I first thought, that a Palm-BBDB-client would be the easiest way to
go. But some other Palm applications interact with the Addressbook and
addresses wouldn't be accessible anymore if they were dealt with by a
proprietary application. I recently started using Datebk4 which
integrates the Palm-Addressbook very nicely. I wouldn't want to loose
this capability.
Cheers,
Arnd.
--
Arnd Kohrs - Institut Eurecom - http://www.eurecom.fr/~kohrs
The Active WebMuseum: Your personalized access to art paintings.
Visit now -> http://www.eurecom.fr/~kohrs/museum.html
_______________________________________________
bbdb-info mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/bbdb-info
