From: "Roland Winkler" <winkler@gnu.org>
To: emacs-devel@gnu.org
Cc: jwiegley@gmail.com
Subject: Re: [ELPA] Package proposal: EBDB
Date: Mon, 7 Aug 2017 10:12:52 +1200 [thread overview]
Message-ID: <37988.94742.967971.22919@gargle.gargle.HOWL> (raw)
In-Reply-To: m2lgn23gha.fsf@newartisans.com
> 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.
next reply other threads:[~2017-08-06 22:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-06 22:12 Roland Winkler [this message]
2017-08-07 0:44 ` [ELPA] Package proposal: EBDB Eric Abrahamsen
-- strict thread matches above, loose matches on Subject: below --
2017-07-30 19:18 Eric Abrahamsen
2017-07-31 0:49 ` Richard Stallman
2017-07-31 3:10 ` Eli Zaretskii
2017-07-31 3:12 ` Eric Abrahamsen
2017-07-31 3:28 ` Eli Zaretskii
2017-07-31 3:30 ` Eric Abrahamsen
2017-08-09 21:17 ` Eric Abrahamsen
2017-08-13 1:03 ` Eric Abrahamsen
2017-08-13 21:47 ` Stefan Monnier
2017-08-14 1:44 ` Eric Abrahamsen
2017-08-14 9:45 ` Stefan Monnier
2017-08-14 15:59 ` Eric Abrahamsen
2017-08-14 23:15 ` Stefan Monnier
2017-08-14 23:50 ` Eric Abrahamsen
2017-08-15 7:49 ` Stefan Monnier
2017-08-15 15:30 ` Eric Abrahamsen
2017-08-17 16:57 ` Eric Abrahamsen
2017-08-17 22:21 ` Stefan Monnier
2017-08-17 22:52 ` Eric Abrahamsen
2017-08-17 23:27 ` Stefan Monnier
2017-08-17 23:31 ` Eric Abrahamsen
2017-08-01 5:33 ` John Wiegley
2017-08-01 16:04 ` Eric Abrahamsen
2017-08-01 22:25 ` John Wiegley
2017-08-01 23:52 ` Eric Abrahamsen
2017-08-02 1:28 ` John Wiegley
2017-08-02 3:08 ` Eric Abrahamsen
2017-08-01 5:58 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37988.94742.967971.22919@gargle.gargle.HOWL \
--to=winkler@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jwiegley@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.