[ELPA] Package proposal: EBDB

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[ELPA] Package proposal: EBDB

Eric Abrahamsen-2
Hi all,

I'd like to propose the following package for inclusion in ELPA:
https://github.com/girzel/ebdb

It's a port/re-write of BBDB using the EIEIO libraries.

Perhaps apropos of the recent copyright discussions: there's a fair
bit of BBDB code still in there. I haven't gone through and measured,
but my top-of-the-head guess is around 15-20%. I've noted this fact in
the comments sections of the files, including the names of original
authors where applicable. I was trying to be polite, but besides the
etiquette question I suppose there might be a copyright issue here.

Can anyone advise? I'd be happy to go through and figure out exactly
how much (and which parts) of the code is original to BBDB, if that's
relevant.

My other question is: if I require the cl-generic package for
backwards compatibility, what's the earliest Emacs version I can
expect to be compatible with? I'm also using seq 2.0 and pcase, and
seq at least says it wants Emacs 25.1 or up, so I guess that's my
floor, regardless...

Thanks,
Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

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

  > Perhaps apropos of the recent copyright discussions: there's a fair
  > bit of BBDB code still in there. I haven't gone through and measured,
  > but my top-of-the-head guess is around 15-20%. I've noted this fact in
  > the comments sections of the files, including the names of original
  > authors where applicable.

Alas, this does raise a copyright issue.  To include this in Emacs, we
need to get legal papers from all the contributors of code that is
still in your version (including you).  With the exception of anyone
whose contributions to Emacs (including this package) will be minimal
(under 10 lines or so).

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eli Zaretskii
> From: Richard Stallman <[hidden email]>
> Date: Sun, 30 Jul 2017 20:49:56 -0400
> Cc: [hidden email]
>
> Alas, this does raise a copyright issue.  To include this in Emacs, we
> need to get legal papers from all the contributors of code that is
> still in your version (including you).  With the exception of anyone
> whose contributions to Emacs (including this package) will be minimal
> (under 10 lines or so).

Another exceptions is people who already have a copyright assignment
on file for Emacs.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
In reply to this post by Richard Stallman
Richard Stallman <[hidden email]> writes:

> [[[ 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. ]]]
>
>   > Perhaps apropos of the recent copyright discussions: there's a fair
>   > bit of BBDB code still in there. I haven't gone through and measured,
>   > but my top-of-the-head guess is around 15-20%. I've noted this fact in
>   > the comments sections of the files, including the names of original
>   > authors where applicable.
>
> Alas, this does raise a copyright issue.  To include this in Emacs, we
> need to get legal papers from all the contributors of code that is
> still in your version (including you).  With the exception of anyone
> whose contributions to Emacs (including this package) will be minimal
> (under 10 lines or so).

Okay, I guess that's not a surprise. I'll figure out which code was
likely written by whom, and come up with a list of names. If I raise
them here, can someone help me check if they've got assignment?

As Eli mentions, I bet many of them (including myself) have already
signed the papers.

Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eli Zaretskii
> From: Eric Abrahamsen <[hidden email]>
> Date: Sun, 30 Jul 2017 20:12:51 -0700
>
> As Eli mentions, I bet many of them (including myself) have already
> signed the papers.

You can ask me to check about specific names, if you want.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
Eli Zaretskii <[hidden email]> writes:

>> From: Eric Abrahamsen <[hidden email]>
>> Date: Sun, 30 Jul 2017 20:12:51 -0700
>>
>> As Eli mentions, I bet many of them (including myself) have already
>> signed the papers.
>
> You can ask me to check about specific names, if you want.

Thanks, I'll do that.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

John Wiegley
In reply to this post by Eric Abrahamsen-2
>>>>> "EA" == Eric Abrahamsen <[hidden email]> writes:

EA> It's a port/re-write of BBDB using the EIEIO libraries.

Can you explain the benefit of including this work into Emacs?  Specifically,
does it solve problems being encountered with the current BBDB, or does it
pave the way for new work?

Thanks,
--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Stefan Monnier
In reply to this post by Eric Abrahamsen-2
> It's a port/re-write of BBDB using the EIEIO libraries.
> Perhaps apropos of the recent copyright discussions: there's a fair
> bit of BBDB code still in there.

BTW, which BBDB are we talking about, here.
Is it the BBDB v2, or BBDB v3?


        Stefan "presuming v3"


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
In reply to this post by John Wiegley
John Wiegley <[hidden email]> writes:

>>>>>> "EA" == Eric Abrahamsen <[hidden email]> writes:
>
> EA> It's a port/re-write of BBDB using the EIEIO libraries.
>
> Can you explain the benefit of including this work into Emacs?  Specifically,
> does it solve problems being encountered with the current BBDB, or does it
> pave the way for new work?

It was originally meant to be a set of patches to BBDB, but snowballed
from there. My feeling was that the original package was inflexible, and
very difficult to extend. EBDB is made to be extensible: multiple
databases, an internationalization mechanism, hooks for integration into
other packages, subclassable records and fields that can have arbitrary
behavior... The code as it stands offers a few solid benefits over BBDB,
but most importantly there's a lot of room for building on top of it.
The class/generic method approach means that other packages could add
all kinds of new behavior to EBDB simply by being loaded.

Probably some of it did end up being new code for new code's sake...

I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's
what it is?

Stefan Monnier <[hidden email]> writes:

>> It's a port/re-write of BBDB using the EIEIO libraries.
>> Perhaps apropos of the recent copyright discussions: there's a fair
>> bit of BBDB code still in there.
>
> BTW, which BBDB are we talking about, here.
> Is it the BBDB v2, or BBDB v3?
>
>
>         Stefan "presuming v3"

Yup, I started out with version 3.

Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

John Wiegley
>>>>> "EA" == Eric Abrahamsen <[hidden email]> writes:

EA> I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's what
EA> it is?

Yes, that's what certainly it's intended to be/mean, from my point of view.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
John Wiegley <[hidden email]> writes:

>>>>>> "EA" == Eric Abrahamsen <[hidden email]> writes:
>
> EA> I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's what
> EA> it is?
>
> Yes, that's what certainly it's intended to be/mean, from my point of view.

Good to know.

I guess my arguments for the package are pretty much what I stated
earlier, then. The present BBDB is limited in that record fields are
just key-value pairs, for the most part strings. If you want to add a
new type of field, you need to add branches to about a dozen `cond'
statements throughout the BBDB codebase. In EBDB, new field types can be
added via an external library. Likewise, the behavior of existing fields
(and records and databases) can be altered with external libraries. EBDB
fields can have arbitrarily complex data slots and behavior.

Records can be of different types. People and organizations are built
in, other record types can be added. Databases are likewise
subclass-able.

I think EBDB's internationalization framework is important. BBDB is
fairly US-centric. EBDB can provide very fine-grained behavior for
phones, addresses and names from various countries/locales/scripts. I
have so far only scratched my own itch, with a China-specific library,
but all the hooks are there.

At present EBDB has some advantages (like multiple databases, record
UUIDs, multiple buffers) that could be added to BBDB as well. But I
think the points above are things that could not be reasonably added to
BBDB as it stands: that was the point of the rewrite.

Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

John Wiegley
>>>>> "EA" == Eric Abrahamsen <[hidden email]> writes:

EA> I guess my arguments for the package are pretty much what I stated
EA> earlier, then. The present BBDB is limited in that record fields are just
EA> key-value pairs, for the most part strings. If you want to add a new type
EA> of field, you need to add branches to about a dozen `cond' statements
EA> throughout the BBDB codebase. In EBDB, new field types can be added via an
EA> external library. Likewise, the behavior of existing fields (and records
EA> and databases) can be altered with external libraries. EBDB fields can
EA> have arbitrarily complex data slots and behavior.

This paragraph is enough for me to want it. :) The ability to make BBDB
extensible in future without requiring core changes is definitely a positive
thing.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
John Wiegley <[hidden email]> writes:

>>>>>> "EA" == Eric Abrahamsen <[hidden email]> writes:
>
> EA> I guess my arguments for the package are pretty much what I stated
> EA> earlier, then. The present BBDB is limited in that record fields are just
> EA> key-value pairs, for the most part strings. If you want to add a new type
> EA> of field, you need to add branches to about a dozen `cond' statements
> EA> throughout the BBDB codebase. In EBDB, new field types can be added via an
> EA> external library. Likewise, the behavior of existing fields (and records
> EA> and databases) can be altered with external libraries. EBDB fields can
> EA> have arbitrarily complex data slots and behavior.
>
> This paragraph is enough for me to want it. :) The ability to make BBDB
> extensible in future without requiring core changes is definitely a positive
> thing.

Well, good! I'm bad at pitching, but I wouldn't have put all this work
in if I didn't think it was a fundamental improvement. The goal is a
fairly tight core of code that doesn't need to know about the
particulars of various database, record and field classes.

I'll continue sorting out the copyright questions.

Thanks,
Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Roland Winkler-5
In reply to this post by Eric Abrahamsen-2

> The ability to make BBDB extensible in future without requiring
> core changes is definitely a positive thing.

I agree, using, e.g., country-specific libraries can be a great way
of extending EBDB.  But this can also cause problems:

- Writing country-specific libraries for EBDB can be a fair bit of
  work.  Someone may develop a library for country XYZ up to the
  point "it works for me".  With the complexity of EBDB the
  developer may not notice / not care that some "irrelevant"
  features do not work.  When other users want to use the library,
  they can be stuck.

- Yet worse: "plain" users may have some records from country XYZ in
  their database, using the EBDB library for XYZ.  At some point,
  the very core of the EBDB code base may get updated in a way that
  also requires an update of the country-specific EBDB libraries.
  But the maintainer of the XYZ library may have disappeared from
  the stage for whatever reason.  What can the users do?  The EBDB
  database of a user might become unusable if its XYZ part cannot be
  read anymore.

  The opposite is also possible: It may turn out that it would be
  nice to update the EBDB code base in a way that also requires an
  update of the EBDB country-specific "add-on libraries" (or any
  other add-on libraries handling certain new fields for EBDB).  If
  there are many such country-specific add-on libraries out in the
  wild, it may become difficult to update the EBDB code base without
  breaking EBDB for many users.

  (Having developed BBDB for some time, I find it hard to predict
  when the code base of BBDB may have reached a level of maturity
  that allowed me to exclude the possibility of any further
  upgrades, say, in the format of the BBDB database files.  Then I
  am glad that such updates of BBDB can include the code to migrate
  the BBDB database files of the users.)

  (BBDB allows the user to customize the handling of addresses in a
  country-specific way; but this does not affect what is being
  stored in the database file using a universal, country-independent
  format.)

- In the worst case, also legal problems may arise: it may not be
  possible that someone else updates the code for the XYZ library.
  (But I am not a lawyer who could predict the details of such
  scenarios.)

I guess that to some extent these are generic aspects of an
object-oriented programming model, which is something I am less
familiar with in such a context.  Maybe others can comment.

It is certainly a [EB]BDB-specific issue that any code development
needs to keep in mind that many users already bring along their
database files.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
"Roland Winkler" <[hidden email]> writes:

>> The ability to make BBDB extensible in future without requiring
>> core changes is definitely a positive thing.
>
> I agree, using, e.g., country-specific libraries can be a great way
> of extending EBDB.  But this can also cause problems:

All of these are very valid points. A couple of responses below.

> - Writing country-specific libraries for EBDB can be a fair bit of
>   work.  Someone may develop a library for country XYZ up to the
>   point "it works for me".  With the complexity of EBDB the
>   developer may not notice / not care that some "irrelevant"
>   features do not work.  When other users want to use the library,
>   they can be stuck.
>
> - Yet worse: "plain" users may have some records from country XYZ in
>   their database, using the EBDB library for XYZ.  At some point,
>   the very core of the EBDB code base may get updated in a way that
>   also requires an update of the country-specific EBDB libraries.
>   But the maintainer of the XYZ library may have disappeared from
>   the stage for whatever reason.  What can the users do?  The EBDB
>   database of a user might become unusable if its XYZ part cannot be
>   read anymore.
>
>   The opposite is also possible: It may turn out that it would be
>   nice to update the EBDB code base in a way that also requires an
>   update of the EBDB country-specific "add-on libraries" (or any
>   other add-on libraries handling certain new fields for EBDB).  If
>   there are many such country-specific add-on libraries out in the
>   wild, it may become difficult to update the EBDB code base without
>   breaking EBDB for many users.
>
>   (Having developed BBDB for some time, I find it hard to predict
>   when the code base of BBDB may have reached a level of maturity
>   that allowed me to exclude the possibility of any further
>   upgrades, say, in the format of the BBDB database files.  Then I
>   am glad that such updates of BBDB can include the code to migrate
>   the BBDB database files of the users.)
>
>   (BBDB allows the user to customize the handling of addresses in a
>   country-specific way; but this does not affect what is being
>   stored in the database file using a universal, country-independent
>   format.)

EBDB's internationalization framework doesn't alter data structures in
any way -- that was a basic principle. It only affects methods that
read, parse and display field data. In the (likely) event that a country
library gets out of step with the main codebase, errors may occur, but
all a user would have to do is unload the problematic library.

> - In the worst case, also legal problems may arise: it may not be
>   possible that someone else updates the code for the XYZ library.
>   (But I am not a lawyer who could predict the details of such
>   scenarios.)

My idea was to ask that internationalization libraries live in ELPA
(I've been talking to Feng Shu, who contributed to the China library,
about this issue). The recent copyright discussions on this list have
touched on Emacs maintainers' ability to push to ELPA packages when
necessary, and I think this is a perfect example. If a country library
is suddenly abandoned, someone with ELPA access could do some emergency
surgery to at least stop errors.

Of course, you can't stop people pushing packages to Melpa, but control
is only possible up to a point.

The stability of the data structures and API is another question, one I
was planning to think about once the number of EBDB users hit the double
digits :)

> I guess that to some extent these are generic aspects of an
> object-oriented programming model, which is something I am less
> familiar with in such a context.  Maybe others can comment.

I've become very, very aware of the pitfalls of [e]lisp's OO model while
working on this package. Generic methods are essentially cond branches
that don't have to live within the cond statement. That's awesome
because cond branches can be defined anywhere. It's a nightmare
because... cond branches can be defined anywhere. It's magic, with both
the positive and negative implications of "magic".

Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
In reply to this post by Richard Stallman
Richard Stallman <[hidden email]> writes:

> [[[ 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. ]]]
>
>   > Perhaps apropos of the recent copyright discussions: there's a fair
>   > bit of BBDB code still in there. I haven't gone through and measured,
>   > but my top-of-the-head guess is around 15-20%. I've noted this fact in
>   > the comments sections of the files, including the names of original
>   > authors where applicable.
>
> Alas, this does raise a copyright issue.  To include this in Emacs, we
> need to get legal papers from all the contributors of code that is
> still in your version (including you).  With the exception of anyone
> whose contributions to Emacs (including this package) will be minimal
> (under 10 lines or so).

Okay, I think I've sorted everything out except for one chunk of one
file, where I haven't yet been able to contact the author. I think I
might just take that chunk out for now, and get the package moving. Just
for background, Roland reminded me of this prior related discussion:

https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01888.html

I think I've cleared everything but that one chunk of ebdb-gnus.

If that's okay, I'll do a few more compiler-warning cleanups, and add
the package as an external.

Thanks,
Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
Eric Abrahamsen <[hidden email]> writes:

> Richard Stallman <[hidden email]> writes:
>
>> [[[ 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. ]]]
>>
>>   > Perhaps apropos of the recent copyright discussions: there's a fair
>>   > bit of BBDB code still in there. I haven't gone through and measured,
>>   > but my top-of-the-head guess is around 15-20%. I've noted this fact in
>>   > the comments sections of the files, including the names of original
>>   > authors where applicable.
>>
>> Alas, this does raise a copyright issue.  To include this in Emacs, we
>> need to get legal papers from all the contributors of code that is
>> still in your version (including you).  With the exception of anyone
>> whose contributions to Emacs (including this package) will be minimal
>> (under 10 lines or so).
>
> Okay, I think I've sorted everything out except for one chunk of one
> file, where I haven't yet been able to contact the author. I think I
> might just take that chunk out for now, and get the package moving. Just
> for background, Roland reminded me of this prior related discussion:
>
> https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01888.html
>
> I think I've cleared everything but that one chunk of ebdb-gnus.
>
> If that's okay, I'll do a few more compiler-warning cleanups, and add
> the package as an external.

Okay, I give up: how do you add an external package?

We add the appropriate line to externals-list in the master branch,
right? Then push that? Then create a new branch, in my case
external/ebdb, and put what in it -- anything? Will something
automatically happen if I push that branch to ELPA?

Thanks
Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Stefan Monnier
> We add the appropriate line to externals-list in the master branch,
> right?  Then push that? Then create a new branch, in my case
> external/ebdb,

First create (and populate) the externals/ebdb branch.  Only once
that is done can you update the externals-list file to point to it.

> and put what in it -- anything?

Pretty much, except:
- .el files in the top-level directory.
- the metadata in the <pkg>.el file (in your case, ebdb.el).

> Will something automatically happen if I push that branch to ELPA?

No, it will happen when you push the change to externals-list.


        Stefan


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Eric Abrahamsen-2
Stefan Monnier <[hidden email]> writes:

>> We add the appropriate line to externals-list in the master branch,
>> right?  Then push that? Then create a new branch, in my case
>> external/ebdb,
>
> First create (and populate) the externals/ebdb branch.  Only once
> that is done can you update the externals-list file to point to it.

Okay, this is what I was confused about. I have to populate the branch
with the code from the existing github repo, obviously I'm not just
copying files in there, I need to clone the repo into it somehow. The
README says:

git clone --reference .. --single-branch --branch externals/PACKAGE $(git config remote.origin.url) PACKAGE

Though I can't tell from the README if that's meant to be the command to
add an external to ELPA, or just pull down an existing external and look
at it. Anyway, running that command just gets me:

Could not find remote branch externals/ebdb to clone

Which is no surprise.

How do I populate the branch?

Eric


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ELPA] Package proposal: EBDB

Stefan Monnier
> Okay, this is what I was confused about. I have to populate the branch
> with the code from the existing github repo, obviously I'm not just
> copying files in there, I need to clone the repo into it somehow. The
> README says:

> git clone --reference .. --single-branch --branch externals/PACKAGE $(git
> config remote.origin.url) PACKAGE

> Though I can't tell from the README if that's meant to be the command to
> add an external to ELPA, or just pull down an existing external and look
> at it. Anyway, running that command just gets me:

"git clone" doesn't modify any existing repository, so that can't be the
command that adds a branch to a repository.

> How do I populate the branch?

IIRC it's something like

    git push gnuelpa master:externals/ebdb

assuming you've configured your local clone of ebdb with something like

    git remote add gnuelpa <user>@git.sv.gnu.org:/srv/git/emacs/elpa.git


-- Stefan


12
Loading...