Re: [ELPA] Package proposal: EBDB

[Eric Abrahamsen <eric@ericabrahamsen.net>]

"Roland Winkler" <winkler@gnu.org> 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