Re: sqlite3

[Madhu <enometh@meer.net>]

* Eli Zaretskii <83bl1ijb3q.fsf@gnu.org> :
Wrote on Wed, 15 Dec 2021 14:39:37 +0200:

>> From: Qiantan Hong <qhong@mit.edu>
>> Date: Tue, 14 Dec 2021 20:38:15 +0000
>> > The use case of accessing existing SQL databases was also
>> > discussed.  And there's no reason to believe no one will ever want
>> > to build a DB application in Emacs Lisp, and no reason to leave
>> > that arena only to Python, JS, and other environments that already
>> > have SQLite bindings.
>> > So yes, potential use cases do exist where sqlite3 will be a bonus,
>> > even before we consider Emacs-specific features that perhaps could
>> > benefit from that.  I would even say that SQLite support is more
>> > important than xwidgets, for example.
>> From what I understand, Tomas’ argument was that for the above use case,
>> linking SQLite3 as a dynamic library to the Emacs core is not strictly better.
>> A subprocess approach also works very well, as in several existing packages.
>
> We will have to agree to disagree about this, and if Thomas indeed
> meant that, I disagree with him as well.
>
>> The above is just to point out some gaps in the reasoning.
>
> There are no gaps in reasoning, just different judgment of proper
> solutions to certain engineering problems.  What is the best solution
> is in many cases a judgment call, not a self-evident conclusion based
> on reasoning.
>
>> Is there a good way that makes some core component (optionally) depends
>> on non-core package?
>
> We can arrange for an option that could be used if people install some
> 3rd-party package, yes.

I didn't like situation with json. There is lisp/json.el (in elisp) and
there is src/json.c which is incompatible.  In a world of ideal emacs
design (like a decade or two ago) I'd have been able to use the
interface which emacs provides and switch the implementation, (say if
the C version was not available).

This was emacs philosophy as i understood it. advice.el was one
example. The APIs are sound and not dependent on implementation bits and
the implementation could be (and was) switched underneath.  Now all the
funding seems to be in tying APIs that emacs provides to the
implementation.

the network interface was another example.  When Emacs is not compiled
without gnutls it was possible to use openssl s_client to get a network
interface and get the job done.  (This has been obsoleted and requires
work before it can work) - and emacs user is now constrained to either
use gnutls or live without ssl, and this is a social-engineering not an
engineering decision.  It was perfectly possible for ssl to work emacs
in an emacs compiled without gnutls, by falling back to s_client, but
this is no longer possible because of decisions which are calculated to
remove that freedom and tie things to an implementation.

And this loss of freedom is implemented in a subtle way, (by the sort of
arguments which have been presented upthread which invoked gnutls)