Re: Difference between EBDB and BBDB

[Eric Abrahamsen]

On 06/25/19 14:08 PM, Drew Adams wrote:
>> > It sounds like, as one big difference, they are incompatible. You
>> > cannot use the same "database" records for both. Is that right?
>> 
>> That's right.
>> 
>> > If so, that's a big difference. If so, does either provide a function
>> > to import records from the other?
>> 
>> EBDB can import from BBDB;
>
> That's great.
>
>> EBDB hasn't been around long enough for
>> anyone to want to go the other way. If someone tried it for a couple
>> months and hated it, but didn't want to lose their contacts, I could
>> pretty easily write a BBDB exporter.
>> 
>> EBDB also has pluggable/swappable databases,
>
> That could be even better, in principle.
>
>> so in theory one could make
>> a database type that stored to a BBDB-usable file, but I'm not sure why
>> you'd want to do that.
>
> Just food for thought:
>
> It's good to be able to separate the use (UI, UX or
> whatever) from the database itself - form of records
> etc.  Regardless of whether it's BBDB or whatever
> else might come along or already exists out there
> somewhere.

That was absolutely my first principle in making this package: the
classes responsible for storage and behavior have nothing to do with the
interface presented to the user. In fact, ebdb.el should be usable as an
API for other packages, while ebdb-com.el should only be responsible for
the ebdb-mode buffers. I wouldn't be surprised if I've screwed up this
separation somewhat, but that was the original idea, and I will fix
relevant bugs!

> A generic way for a user to define her own
> record-to-record mapping (for whatever storage form)
> could help.  It could be a mapping for one-time
> conversion or a mapping to use at runtime to access
> another database directly.

While the documentation doesn't go into this at this point, this is
precisely how the whole system works, right down to the "generic" term:
`cl-defgeneric' is basically how you take control of the whole system.