From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Thu, 16 Dec 2021 15:18:30 +0530 Message-ID: References: <87tufmjyai.fsf@gnus.org> <87lf0nr2b4.fsf@gnus.org> <87czlzjfhs.fsf@logand.com> <87pmpznmw4.fsf@gnus.org> <87a6h3jcfm.fsf@logand.com> <83lf0nj9w4.fsf@gnu.org> <8735mvj5u0.fsf@logand.com> <83fsqvj5jx.fsf@gnu.org> <83bl1ijb3q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31570"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Cancel-Lock: sha1:DDz3E2I4WzKyVzRqE1d2x8KIxvY= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 16 10:53:00 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxnRc-00083n-1R for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Dec 2021 10:53:00 +0100 Original-Received: from localhost ([::1]:48938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxnRb-0000gE-1s for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Dec 2021 04:52:59 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxnN1-0000dO-OA for emacs-devel@gnu.org; Thu, 16 Dec 2021 04:48:15 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:34998) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxnN0-0002LO-5e for emacs-devel@gnu.org; Thu, 16 Dec 2021 04:48:15 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mxnMw-0001OS-M8 for emacs-devel@gnu.org; Thu, 16 Dec 2021 10:48:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:282140 Archived-At: * Eli Zaretskii <83bl1ijb3q.fsf@gnu.org> : Wrote on Wed, 15 Dec 2021 14:39:37 +0200: >> From: Qiantan Hong >> 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)