From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Wed, 15 Dec 2021 14:39:37 +0200 Message-ID: <83bl1ijb3q.fsf@gnu.org> 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> 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="18832"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, tom@logand.com, emacs-devel@gnu.org To: Qiantan Hong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 15 13:47:06 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 1mxTgY-0004ft-Fd for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 13:47:06 +0100 Original-Received: from localhost ([::1]:50162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxTgX-0007dq-8W for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 07:47:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47798) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxTZn-000355-Qa for emacs-devel@gnu.org; Wed, 15 Dec 2021 07:40:08 -0500 Original-Received: from [2001:470:142:3::e] (port=46602 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxTZm-00057G-Ja; Wed, 15 Dec 2021 07:40:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=kGSwmCem6sR+EnUwRQlbtXAzBD97UKf7PBv7ZbjmMTU=; b=A+fufS7Z6R6jLzwf4wRD tYYR7uf4tBPC7SYbRiYu5Rp5aUYoA9xJDugOhQMdx3ERQjPUvtD2u8Vfb7jOF5XoaqM6Ghm8/FhVY lv/+NeGnJVs26chiHzdczzn7lsJOwNIUmKWJyZNXZAAoYyRXZ4PwUF4Rd3qV3N2DbdoI419j6iLmf JWHp6AeG3i71Ur/4bI1cOB1u5c6Q8T+R7kKBD3dRYytEG8gDOsszR0oPXYpiB409alMLjkMK5QayK P5X0tQKUOUeTnDKaSe42Ydk4xRgmITbOtoT+Auy9zDwBOIgOOULMxOmcvEBq27MjvBKNz8V1SsQjN kCWS5fcu6rioeg==; Original-Received: from [87.69.77.57] (port=3146 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxTZd-0005Qo-Qu; Wed, 15 Dec 2021 07:40:00 -0500 In-Reply-To: (message from Qiantan Hong on Tue, 14 Dec 2021 20:38:15 +0000) 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:282026 Archived-At: > From: Qiantan Hong > CC: Tomas Hlavaty , "larsi@gnus.org" , > "emacs-devel@gnu.org" > 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.