From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Roland Winkler" Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] Package proposal: EBDB Date: Mon, 7 Aug 2017 10:12:52 +1200 Message-ID: <37988.94742.967971.22919@gargle.gargle.HOWL> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1502057597 18864 195.159.176.226 (6 Aug 2017 22:13:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 6 Aug 2017 22:13:17 +0000 (UTC) Cc: jwiegley@gmail.com To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 07 00:13:14 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deTnN-0004hT-2m for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2017 00:13:13 +0200 Original-Received: from localhost ([::1]:34465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deTnT-0007V8-AE for ged-emacs-devel@m.gmane.org; Sun, 06 Aug 2017 18:13:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deTnN-0007Uv-2E for emacs-devel@gnu.org; Sun, 06 Aug 2017 18:13:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deTnL-0000ji-Q2 for emacs-devel@gnu.org; Sun, 06 Aug 2017 18:13:13 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deTnF-0000il-Lb; Sun, 06 Aug 2017 18:13:05 -0400 Original-Received: from [130.195.253.47] (port=56493 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1deTnE-0000Js-Ua; Sun, 06 Aug 2017 18:13:05 -0400 In-Reply-To: m2lgn23gha.fsf@newartisans.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217344 Archived-At: > 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.