Re: eudc conversion to bbdb (in bbdb3.1.2?)

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Roland Winkler]

On Sun Nov 15 2015 George McNinch wrote:
> I'm using "git-emacs"
> emacs-version => "25.1.50.1"
> and elpa bbdb
> bbdb-version => "3.1.2" (via ELPA)
> 
> If I do M-x eudc-query, find a record corresponding to a contact not in
> my bbdb , and try to add it to my bbdb via "b" (more precisely, by the
> function "eudc-try-bbdb-insert")
> 
> I get an error - this is what appears in *Messages*:

The BBDB interface in EUDC assumes BBDB 2.
With the release of BBDB 3, EUDC should be updated to interact with
BBDB 3.

Roland

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Thomas Fitzsimmons]

"Roland Winkler" <winkler@gnu.org> writes:

> On Sun Nov 15 2015 George McNinch wrote:
>> I'm using "git-emacs"
>> emacs-version => "25.1.50.1"
>> and elpa bbdb
>> bbdb-version => "3.1.2" (via ELPA)

Which ELPA?  MELPA?

>> If I do M-x eudc-query, find a record corresponding to a contact not in
>> my bbdb , and try to add it to my bbdb via "b" (more precisely, by the
>> function "eudc-try-bbdb-insert")
>> 
>> I get an error - this is what appears in *Messages*:
>
> The BBDB interface in EUDC assumes BBDB 2.
> With the release of BBDB 3, EUDC should be updated to interact with
> BBDB 3.

The version of EUDC in question should be able to read bbdb 2.x or bbdb
3.x formatted databases transparently.  But I haven't done much testing
with eudc-query and writing BBDB entries from there.  Can you file a bug
against Emacs eudc, with a series of steps to reproduce?

That said, it's hard to even know what combination to test because EUDC
is in Emacs core, whereas BBDB is either provided by the distro, or
built from source, or installed from some another ELPA.

Managing the EUDC/BBDB dependency would be much easier if BBDB were in
GNU ELPA or core.

I guess now is a good time to revisit: is there any chance of BBDB ever
getting assignment paperwork from its existing contributors?  As I
understand it, though BBDB 3 is largely a rewrite it still uses code
patterns from prior contributors that may not be clear from a copyright
standpoint?

Thanks,
Thomas

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Roland Winkler]

On Wed Nov 18 2015 Thomas Fitzsimmons wrote:
> The version of EUDC in question should be able to read bbdb 2.x or
> bbdb 3.x formatted databases transparently.  But I haven't done
> much testing with eudc-query and writing BBDB entries from there.

Ah, thanks, that's good to know.  Lately I did not look at Emacs git.

> I guess now is a good time to revisit: is there any chance of BBDB
> ever getting assignment paperwork from its existing contributors?
> As I understand it, though BBDB 3 is largely a rewrite it still
> uses code patterns from prior contributors that may not be clear
> from a copyright standpoint?

I believe it is fair to say that the core of BBDB has been rewritten
completely (the three files bbdb.el, bbdb-com.el and bbdb-mua.el), also
some add-ons are "clean" (bbdb-anniv.el, bbdb-ispell.el,
bbdb-snarf.el, bbdb-pgp.el)

Loose ends include the add-ons bbdb-sc.el, bbdb-print.el and
mua-specific pieces of code in bbdb-gnus.el and bbdb-vm.el.

One option could be to incorporate the core of BBDB into GNU Emacs
and keep the loose ends in savannah.nongnu.org.  BBDB has a long
history of having a core plus many add-ons.

Roland

Adding BBDB 3 core to Emacs (was: eudc conversion to bbdb (in bbdb3.1.2?))

[Thomas Fitzsimmons]

"Roland Winkler" <winkler@gnu.org> writes:

> On Wed Nov 18 2015 Thomas Fitzsimmons wrote:
>> The version of EUDC in question should be able to read bbdb 2.x or
>> bbdb 3.x formatted databases transparently.  But I haven't done
>> much testing with eudc-query and writing BBDB entries from there.
>
> Ah, thanks, that's good to know.  Lately I did not look at Emacs git.
>
>> I guess now is a good time to revisit: is there any chance of BBDB
>> ever getting assignment paperwork from its existing contributors?
>> As I understand it, though BBDB 3 is largely a rewrite it still
>> uses code patterns from prior contributors that may not be clear
>> from a copyright standpoint?
>
> I believe it is fair to say that the core of BBDB has been rewritten
> completely (the three files bbdb.el, bbdb-com.el and bbdb-mua.el), also
> some add-ons are "clean" (bbdb-anniv.el, bbdb-ispell.el,
> bbdb-snarf.el, bbdb-pgp.el)
>
> Loose ends include the add-ons bbdb-sc.el, bbdb-print.el and
> mua-specific pieces of code in bbdb-gnus.el and bbdb-vm.el.
>
> One option could be to incorporate the core of BBDB into GNU Emacs
> and keep the loose ends in savannah.nongnu.org.  BBDB has a long
> history of having a core plus many add-ons.

I really like this idea.  Then we could count on BBDB 3 (core) being in
Emacs core.  We could fix EUDC to always enable the BBDB backend by
default, include an Info node in the manual for BBDB itself and fix the
EUDC Info nodes to be BBDB 3-specific.

John, Richard what do you think of this plan?

Thomas

Re: Adding BBDB 3 core to Emacs

[John Wiegley]

>>>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> I really like this idea. Then we could count on BBDB 3 (core) being in Emacs
> core. We could fix EUDC to always enable the BBDB backend by default,
> include an Info node in the manual for BBDB itself and fix the EUDC Info
> nodes to be BBDB 3-specific.

I would much prefer this to be in "tarball ELPA", so that it is included in
the distribution, but not a focus for the other developers. Would there be any
need to include it within core itself?

John

Re: Adding BBDB 3 core to Emacs

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Sat, 21 Nov 2015 08:56:49 -0800
> Cc: George McNinch <gmcninch@gmail.com>, Roland Winkler <winkler@gnu.org>,
> 	bbdb-info@lists.sourceforge.net, emacs-devel@gnu.org
> 
> >>>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
> 
> > I really like this idea. Then we could count on BBDB 3 (core) being in Emacs
> > core. We could fix EUDC to always enable the BBDB backend by default,
> > include an Info node in the manual for BBDB itself and fix the EUDC Info
> > nodes to be BBDB 3-specific.
> 
> I would much prefer this to be in "tarball ELPA", so that it is included in
> the distribution, but not a focus for the other developers. Would there be any
> need to include it within core itself?

Didn't BBDB have some copyright issues that precluded its distribution
with Emacs or under the same license?  (Apologies if I'm
misremembering.)

Re: Adding BBDB 3 core to Emacs

[Thomas Fitzsimmons]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: John Wiegley <jwiegley@gmail.com>
>> Date: Sat, 21 Nov 2015 08:56:49 -0800
>> Cc: George McNinch <gmcninch@gmail.com>, Roland Winkler <winkler@gnu.org>,
>> 	bbdb-info@lists.sourceforge.net, emacs-devel@gnu.org
>> 
>> >>>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>> 
>> > I really like this idea. Then we could count on BBDB 3 (core) being in Emacs
>> > core. We could fix EUDC to always enable the BBDB backend by default,
>> > include an Info node in the manual for BBDB itself and fix the EUDC Info
>> > nodes to be BBDB 3-specific.
>> 
>> I would much prefer this to be in "tarball ELPA", so that it is included in
>> the distribution, but not a focus for the other developers. Would there be any
>> need to include it within core itself?
>
> Didn't BBDB have some copyright issues that precluded its distribution
> with Emacs or under the same license?  (Apologies if I'm
> misremembering.)

I'm not aware of any licensing issues.  All the files in BBDB 2.x are
either GPLv2 or any later version, or GPLv1 or any later version.

Most BBDB 2.x contributors have not signed FSF copyright assignment
papers though.  From what I've read, there have been attempts to get
paperwork for all BBDB contributors in the past, but they were
unsuccessful.

However, BBDB 3 represents a rewrite of the core portions of the
codebase by Roland.  I did a comparison between BBDB 2.x and BBDB 3
within the last year.  The core parts seem significantly different to
me, and Roland considers them in the clear now.

The proposal here is to split BBDB 3 into two portions; the "bbdb-core"
portion, and a "bbdb-extras" portion for code that is not
copyright-assigned.  "bbdb-core" would be acceptable from a copyright
perspective for inclusion in Emacs core or GNU ELPA.

Thomas

Re: Adding BBDB 3 core to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > However, BBDB 3 represents a rewrite of the core portions of the
  > codebase by Roland.  I did a comparison between BBDB 2.x and BBDB 3
  > within the last year.  The core parts seem significantly different to
  > me, and Roland considers them in the clear now.

  > The proposal here is to split BBDB 3 into two portions; the "bbdb-core"
  > portion, and a "bbdb-extras" portion for code that is not
  > copyright-assigned.  "bbdb-core" would be acceptable from a copyright
  > perspective for inclusion in Emacs core or GNU ELPA.

That's a fine plan.  I am glad this is now possible.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding BBDB 3 core to Emacs

[Roland Winkler]

On Sat Nov 21 2015 Eli Zaretskii wrote:
> Didn't BBDB have some copyright issues that precluded its
> distribution with Emacs or under the same license?  (Apologies if
> I'm misremembering.)

No, you are perfectly right.  BBDB v2 *did* have copyright issues.
BBDB v3 on savannah.nongnu.org is essentially a complete rewrite,
where all authors who contributed new code to BBDB v3 assigned their
copyright to the FSF.  This covers the core of BBDB v3.  A few loose
ends include add-ons to the core of BBDB which survived the upgrade
to v3.  Now the question is how to deal with the current situation.
The proposal is to integrate the core of BBDB v3 more tightly with
GNU Emacs, yet there is more than one option for this: either the
core of BBDB becomes part of GNU Emacs itself or it goes into GNU
Elpa.  (In either case the "loose ends" can stay in
savannah.nongnu.org till hopefully one day their cases are resolved,
too.  But that's obviously less urgent.)

Roland

Re: Adding BBDB 3 core to Emacs

[Stephen J. Turnbull]

Roland Winkler writes:

 > No, you are perfectly right.  BBDB v2 *did* have copyright issues.

BBDB v3 still has issues, as it has a complex API which is under
previous copyright AFAIK.

 > BBDB v3 on savannah.nongnu.org is essentially a complete rewrite,

"Essentially" as understood by programmers is rarely anything close to
what a lawyer thinks of as an independent work not considered a
derivative.  I doubt *any* of the newly assigned work was done without
looking at the original, and very likely most still uses original
internal variable names, structures, algorithms, etc.  You'd better
check with the lawyers.

Re: Adding BBDB 3 core to Emacs

[Roland Winkler]

On Sun Nov 22 2015 Stephen J. Turnbull wrote:
>  > BBDB v3 on savannah.nongnu.org is essentially a complete rewrite,
> 
> "Essentially" as understood by programmers is rarely anything
> close to what a lawyer thinks of as an independent work not
> considered a derivative.  I doubt *any* of the newly assigned work
> was done without looking at the original, and very likely most
> still uses original internal variable names, structures,
> algorithms, etc.  You'd better check with the lawyers.

Have you looked at the new code?

Roland

Re: Adding BBDB 3 core to Emacs

[Stephen J. Turnbull]

Roland Winkler writes:

 > Have you looked at the new code?

I don't need to; I trust you that 'most every line has been changed,
and many functions completely rewritten.  The point is that old
configuration works with very little change with the new code.
Therefore it stinks of "derivative work" to me.

I'm just saying somebody should get the opinion of someone whose nose
knows the difference between "derivative work" and "Chanel No. 5".
IANAL and TINLA: I don't claim to.

Regards,

Re: Adding BBDB 3 core to Emacs

[Roland Winkler]

On Mon Nov 23 2015 Stephen J. Turnbull wrote:
>  > Have you looked at the new code?
> 
> I don't need to; I trust you that 'most every line has been changed,
> and many functions completely rewritten.  The point is that old
> configuration works with very little change with the new code.
> Therefore it stinks of "derivative work" to me.

Your view would never allow a program like libreoffice to come into
existence.

(Users who switched from old to new BBDB suffered a lot in the sense
that none of their old configurations worked anymore.  But our
current discussion was a major reason not to worry about the old
code base.)

Re: Adding BBDB 3 core to Emacs

[Stephen J. Turnbull]

Roland Winkler writes:
 > On Mon Nov 23 2015 Stephen J. Turnbull wrote:
 > >  > Have you looked at the new code?
 > > 
 > > I don't need to; I trust you that 'most every line has been changed,
 > > and many functions completely rewritten.  The point is that old
 > > configuration works with very little change with the new code.
 > > Therefore it stinks of "derivative work" to me.
 > 
 > Your view

It's not "my view", it's Emacs project policy as designed by Richard
Stallman with the advice of the FSF lawyers.  Ask the AUCTeX guys how
picky it gets. :-(

*My* view is that I have always disagreed with FSF legal strategy on
both philosophical and tactical grounds, but until the FSF changes its
position, I'm going to help it implement its policy.  A united front
is far more important than my personal, non-expert opinion.

 > would never allow a program like libreoffice to come into existence.

It's not what others can do with BBDB code that matters.  AFAIK
there's no doubt that it's GPL.  What matters is whether the FSF legal
staff can be convinced it's not encumbered by third-party copyrights.

Re: Adding BBDB 3 core to Emacs

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Roland Winkler writes:
>  > On Mon Nov 23 2015 Stephen J. Turnbull wrote:
>  > >  > Have you looked at the new code?
>  > > 
>  > > I don't need to; I trust you that 'most every line has been
>  > > changed, and many functions completely rewritten.  The point is
>  > > that old configuration works with very little change with the new
>  > > code.  Therefore it stinks of "derivative work" to me.
>  > 
>  > Your view
>
> It's not "my view", it's Emacs project policy as designed by Richard
> Stallman with the advice of the FSF lawyers.  Ask the AUCTeX guys how
> picky it gets. :-(

The AUCTeX guys did not have problems with reimplementations being
tagged as problematic.  The principal problem was that we had about a
decade of loosely attributed work.  We've managed to collect assignments
from all the known main contributors and past maintainers and most
people with known or unknown contributions (basically mentioned in the
"thanks" section but without an actual record, some not even remembering
that they should have contributed anything).  So we are in "to the best
of our knowledge" territory with regard to assignments and fairly sure
that we can fill in any potential holes caused by people complaining
about AUCTeX's distribution under (c) FSF claims.

That was an ugly and ungrateful mess to deal with, but theories of weak
or strong derivation did not play into it.  Yet.  There were a few
rewrites from scratch for style files where the original author could no
longer be reached or bothered.  Those files were basically "flat" with
regard to creative content, namely containing no tricky or high-quality
code or even any new data structures/algorithms.

So with regard to the problem you are talking about, AUCTeX does not
really provide any data point either way.

>  > would never allow a program like libreoffice to come into
>  > existence.
>
> It's not what others can do with BBDB code that matters.  AFAIK
> there's no doubt that it's GPL.  What matters is whether the FSF legal
> staff can be convinced it's not encumbered by third-party copyrights.

I have no knowledge of BBDB myself so I cannot sport an opinion on that.

-- 
David Kastrup

Re: Adding BBDB 3 core to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The previous version of BBDB was released under GPL 2-or-later, right?
So it is no problem if a little remains that's under the copyright of the
authors of the previous version.  

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding BBDB 3 core to Emacs

[Roland Winkler]

On Sun Nov 22 2015 Richard Stallman wrote:
> The previous version of BBDB was released under GPL 2-or-later, right?

According to http://bbdb.sourceforge.net, the last version of the
"old" BBDB was 2.35 released on January 30, 2007.

Most lisp files in this tar ball specify GPL 2-or-later.

The files bbdb-ftp.el, bbdb-gnus.el, bbdb-mhe.el, bbdb-print.el,
bbdb-rmail.el, bbdb-sc.el, bbdb-vm.el were released under GPL
1-or-later.

The file bbdb-snarf.el says GPL 1.

The file bbdb-merge.el says very briefly "GPL" without any reference
to a particular version.

Roland

Re: Adding BBDB 3 core to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The file bbdb-snarf.el says GPL 1.

Can you arrange to completely discard that?

  > The file bbdb-merge.el says very briefly "GPL" without any reference
  > to a particular version.

That means it allows any GPL version, so there is no problem with it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding BBDB 3 core to Emacs

[Roland Winkler]

On Mon Nov 23 2015 Richard Stallman wrote:
>   > The file bbdb-snarf.el says GPL 1.
> 
> Can you arrange to completely discard that?

The new BBDB also has a file bbdb-snarf.el which is a complete
rewrite of the old file, where only the general concept of "snarfing
records into BBDB" survived.

This snarfing can be a neat thing, but it is certainly an add-on to
the BBDB core.  So to avoid whatever problems, it can remain with
other add-ons at savannah.nongnu.org without affecting BBDB core
functionality.

Actually, the file says:

;;; Copyright (C) 1997 by John Heidemann <johnh@isi.edu>.
;;; $Id: bbdb-snarf.el,v 1.44 2006/05/26 21:20:07 fenk Exp $
;;;
;;; This file is free software; you can redistribute it and/or modify
;;; it under the terms of the GNU General Public License as published
;;; by the Free Software Foundation version 1.

John Heidemann has an FSF copyright assignment on file and I can
check with him about bbdb-snarf.el.  The above email address appears
to be up-to-date.  What kind of document would the FSF need from
him for this file?

The subsequent maintainer of the old bbdb-snarf.el, Robert
Widhopf-Fenk, assigned "past and future changes" to the FSF.  Is
this sufficient?  I could also try to contact him, though I have
found him difficult to reach.

Would this be sufficient for "Copyright by the FSF"?

Thanks,

Roland

Re: Adding BBDB 3 core to Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The new BBDB also has a file bbdb-snarf.el which is a complete
  > rewrite of the old file, where only the general concept of "snarfing
  > records into BBDB" survived.

That eliminates any problem from the old bbdb-snarf.el.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding BBDB 3 core to Emacs

[Thomas Fitzsimmons]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> I really like this idea. Then we could count on BBDB 3 (core) being in Emacs
>> core. We could fix EUDC to always enable the BBDB backend by default,
>> include an Info node in the manual for BBDB itself and fix the EUDC Info
>> nodes to be BBDB 3-specific.
>
> I would much prefer this to be in "tarball ELPA", so that it is included in
> the distribution, but not a focus for the other developers. Would there be any
> need to include it within core itself?

The main reason is that there are lots of references and dependencies in
core on BBDB already, e.g. Gnus, Org, EUDC.  I'd like to satisfy those
dependencies with something stable, available and easily testable.  That
implies putting BBDB in core.

If Gnus, Org, EUDC move to "tarball ELPA" eventually, then BBDB could
move too.  At that point, hopefully the BBDB APIs used would have had
time to stabilize because of their maintenance in Emacs core.

Or, the other argument is that BBDB could become part of the core
"platform" that provides contact management features to other Emacs
packages.  That would probably imply that long-term BBDB should stay in
core.

But in either case, short term (in Emacs feature roadmap timescales :-))
I think it would make sense to put "BBDB core" in Emacs core.

Thomas

Re: Adding BBDB 3 core to Emacs

[raman]

1+ -- I think contact management is a core platform feature, and at
present, it remains largely out of reach of the average emacs user.

We've had a lot of discussion lately about Emacs as an iDE; that
discussion focuses on aspects of Emacs relevant to software
development. But Emacs' core strengths derive from it being a
well-rounded platform where one can  create all forms of content --
including software, and communication  is a key aspect of collaboration
that aids in content creation --  

-- 

Re: Adding BBDB 3 core to Emacs

[John Wiegley]

>>>>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> If Gnus, Org, EUDC move to "tarball ELPA" eventually, then BBDB could move
> too.

Yes, I would like to see that happen.

> Or, the other argument is that BBDB could become part of the core "platform"
> that provides contact management features to other Emacs packages. That
> would probably imply that long-term BBDB should stay in core.

That could be an argument for being in core, yes.

> But in either case, short term (in Emacs feature roadmap timescales :-)) I
> think it would make sense to put "BBDB core" in Emacs core.

If other core packages depend on it, then yes, until those others move to
ELPA, core would be the right place.

John

Re: Adding BBDB 3 core to Emacs

[Roland Winkler]

On Sat Nov 21 2015 John Wiegley wrote:
> I would much prefer this to be in "tarball ELPA", so that it is
> included in the distribution, but not a focus for the other
> developers. Would there be any need to include it within core
> itself?
 
The question is to what extent one wants to consider BBDB a core
functionality that other packages rely upon.  I myself see the pros
and cons of both sides and therefore do not have strong feelings in
either direction.  Yet I certainly hope that in either case such a
decision will not be carved in stone so that if necessary it can be
reviewed once more in later times.

Roland

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Barak A. Pearlmutter]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

Or at the very least, to check the version for compatibility.

But this does bring up a deeper issue, namely exposing a documented stable
bbdb API might be a good idea.

--Barak.

[-- Attachment #2: Type: text/html, Size: 228 bytes --]

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Roland Winkler]

On Wed Nov 18 2015 Barak A. Pearlmutter wrote:
> But this does bring up a deeper issue, namely exposing a
> documented stable bbdb API might be a good idea.

The question is what kind of scenarios the API is supposed to cover.
I have never thought in much detail about this question.  

- This thread started with how EUDC interacts with BBDB.  Is there a
  list of other packages to be considered here?

- Are we talking about interactive and / or non-interactive
  applications interacting with BBDB ("interactive" in the sense of
  elisp `interactive')?

- What should an interface look like for searching records in the
  database for non-interactive applications?  The macro bbdb-search
  can possibly be further improved.

- Exporting / importing individual fields for a given record already
  has a stable interface via bbdb-record-field and
  bbdb-record-set-field.

- Exporting complete records: is bbdb-record-field sufficient for
  that purpose?

- Currently there is only little support for importing complete
  records (possibly following a previous export).  A major issue are
  imported records that should be merged with existing records.
  Currently BBDB uses elisp `eq' to recognize equal records which is
  an approach that can fail in many ways.  Adding a UUID field to
  every record that gets exported and imported would make this more
  robust.  (We talked about this before, and it is on my agenda,
  though lately my time has been limited.)

- Is there something else?

Roland

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Barak A. Pearlmutter]

I guess was thinking that having a stable and ration API, rather than
just exporting some internal functions etc, might encourage people to
build good conduits to/from Google Contacts, Android, iPhone, skype,
etc etc.

--Barak.

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Roland Winkler]

On Sat Nov 21 2015 Barak A. Pearlmutter wrote:
> I guess was thinking that having a stable and ration API, rather
> than just exporting some internal functions etc, might encourage
> people to build good conduits to/from Google Contacts, Android,
> iPhone, skype, etc etc.

Sure, this was really what my question was about: you talk about
importing / exporting records, and I agree that's an important
thing.  Are there possibly other types of applications, too?

Roland

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Barak A. Pearlmutter]

> importing / exporting records, and I agree that's an important
> thing.  Are there possibly other types of applications, too?

Part of the motivation of making a stable and nice API is that people
might find other unanticipated uses. Letting my imagination run wild:
integration with spelling correction to make it correct names, or a
minor mode to insert hyperlinks on names when in a major mode (like
markdown or latex or texinfo or text) that supports hyperlinks.

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Roland Winkler]

On Sun Nov 22 2015 Barak A. Pearlmutter wrote:
> Part of the motivation of making a stable and nice API is that
> people might find other unanticipated uses. Letting my imagination
> run wild: integration with spelling correction to make it correct
> names,

There is actually already bbdb-ispell.el for this very purpose.

> or a minor mode to insert hyperlinks on names when in a major mode
> (like markdown or latex or texinfo or text) that supports
> hyperlinks.

Good idea!

(I appreciate this brainstorming and encourage others to contribute
as it gives an idea what kind of problems an API could cover.)

Re: eudc conversion to bbdb (in bbdb3.1.2?)

[Eric Abrahamsen]

"Roland Winkler" <winkler@gnu.org> writes:

> On Wed Nov 18 2015 Barak A. Pearlmutter wrote:
>> But this does bring up a deeper issue, namely exposing a
>> documented stable bbdb API might be a good idea.
>
> The question is what kind of scenarios the API is supposed to cover.
> I have never thought in much detail about this question.  
>
> - This thread started with how EUDC interacts with BBDB.  Is there a
>   list of other packages to be considered here?
>
> - Are we talking about interactive and / or non-interactive
>   applications interacting with BBDB ("interactive" in the sense of
>   elisp `interactive')?
>
> - What should an interface look like for searching records in the
>   database for non-interactive applications?  The macro bbdb-search
>   can possibly be further improved.
>
> - Exporting / importing individual fields for a given record already
>   has a stable interface via bbdb-record-field and
>   bbdb-record-set-field.
>
> - Exporting complete records: is bbdb-record-field sufficient for
>   that purpose?
>
> - Currently there is only little support for importing complete
>   records (possibly following a previous export).  A major issue are
>   imported records that should be merged with existing records.
>   Currently BBDB uses elisp `eq' to recognize equal records which is
>   an approach that can fail in many ways.  Adding a UUID field to
>   every record that gets exported and imported would make this more
>   robust.  (We talked about this before, and it is on my agenda,
>   though lately my time has been limited.)
>
> - Is there something else?

I might add to this a clearer API for the "noticing" functionality of
BBDB -- ie, make it easier to write the hooks for "doing things to BBDB
records when you receive mails from/compose mails to those records.

Eric