Difference between EBDB and BBDB

Difference between EBDB and BBDB

[M.R.P. zensky via help-gnu-emacs]

What is the difference between EBDB and BBDB?

Re: Difference between EBDB and BBDB

[Stefan Monnier]

> What is the difference between EBDB and BBDB?

Let's ask Emacs:

    M-: (- #xEBDB #xBBDB)
    ==> 12288


-- Stefan

Re: Difference between EBDB and BBDB

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What is the difference between EBDB and BBDB?
>
> Let's ask Emacs:
>
>     M-: (- #xEBDB #xBBDB)
>     ==> 12288

Here I thought it was 42!

I'm the author of EBDB. The two packages do pretty similar things: EBDB
started out as a refactor/rewrite of BBDB, which has been around a lot
longer. So it still _feels_ very similar, though it's written using
completely different elisp tools. The idea was to make a system that was
much more flexible and extensible than BBDB. EBDB is only reaching
maturity around this time, so a lot of that potential is still in the
future.

Right now I'd say two big differences are multiple record types (there
are separate record types for people and organizations, and records can
have "roles" at multiple organizations) and internationalization
(phones/addresses can be aware of national formats, as can non-English
scripts for names).

Hope that helps,
Eric

RE: Difference between EBDB and BBDB

[Drew Adams]

> Right now I'd say two big differences are multiple record types (there
> are separate record types for people and organizations, and records can
> have "roles" at multiple organizations) and internationalization
> (phones/addresses can be aware of national formats, as can non-English
> scripts for names).

It sounds like, as one big difference, they are incompatible.  You cannot use the same "database" records for both.  Is that right?

If so, that's a big difference.  If so, does either provide a function to import records from the other?

Re: Difference between EBDB and BBDB

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> Right now I'd say two big differences are multiple record types (there
>> are separate record types for people and organizations, and records can
>> have "roles" at multiple organizations) and internationalization
>> (phones/addresses can be aware of national formats, as can non-English
>> scripts for names).
>
> 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; 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, 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.

I forgot EBDB's other major selling-point: it has a manual!

Eric

Re: Difference between EBDB and BBDB

[Xavier Maillard]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Tue, 25 Jun 2019 12:34:23 -0700
> I forgot EBDB's other major selling-point: it has a manual!

+1

That's a huge plus.

        - xma

GPG:  BA4909B7 8F04DE1B

RE: Difference between EBDB and BBDB

[Drew Adams]

> > 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.

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.

> I forgot EBDB's other major selling-point: it has a manual!

Excellent.

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.

Re: Difference between EBDB and BBDB

[Jude DaShiell]

bbdb was not developed at IBM, in that corporation the manual has to be
written first then passed to the programmmers who make manual-conformant
software.

On Tue, 25 Jun 2019, Xavier Maillard wrote:

> Date: Tue, 25 Jun 2019 16:34:38
> From: Xavier Maillard <xavier@maillard.im>
> To: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: help-gnu-emacs@gnu.org, monnier@iro.umontreal.ca
> Subject: Re: Difference between EBDB and BBDB
>
> > From: Eric Abrahamsen <eric@ericabrahamsen.net>
> > Date: Tue, 25 Jun 2019 12:34:23 -0700
> > I forgot EBDB's other major selling-point: it has a manual!
>
> +1
>
> That's a huge plus.
>
>         - xma
>
> GPG:  BA4909B7 8F04DE1B
>
>

-- 

RE: Difference between EBDB and BBDB

[Drew Adams]

> > 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.

The curmudgeon has nothing more to say.  Good job!

Re: Difference between EBDB and BBDB

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> > 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.
>
> The curmudgeon has nothing more to say.  Good job!

I hope it actually lives up to these principles :)