Re: sqlite3

[Qiantan Hong <qhong@mit.edu>]

> On Dec 14, 2021, at 12:27 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Tomas Hlavaty <tom@logand.com>
>> Cc: larsi@gnus.org, emacs-devel@gnu.org
>> Date: Tue, 14 Dec 2021 21:21:11 +0100
>> 
>>> No solution is superior in all use cases.  This is software
>>> engineering, after all.
>> 
>> I was addressing the discussed use-cases, not all possible use-cases.
> 
> 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.

There’s basically no way to integrate xwidgets as an independent package/without 
linking into Emacs, on the other hand, because it changes display code.

The above is just to point out some gaps in the reasoning. That doesn’t mean
your conclusion is right or wrong. From my understanding the single strongest
argument for adding SQLite3 support into core is that other part of the core
(say gnus) might want to depend on it.

Is there a good way that makes some core component (optionally) depends
on non-core package? This might also become a problem for experimenting
my store.el, because one PoC would be providing a backend for org-id, but
orgmode is in the core.