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: Thu, 09 Dec 2021 22:14:39 +0200 Message-ID: <83a6h9tu1c.fsf@gnu.org> References: <87tufmjyai.fsf@gnus.org> <877dcil2sj.fsf@ericabrahamsen.net> <87czm98qi1.fsf@gnu.org> <87o85tcwm0.fsf@ericabrahamsen.net> <874k7ljwkr.fsf@gnus.org> <87fsr5cuzq.fsf@ericabrahamsen.net> <878rwx8mdn.fsf@gnu.org> <87r1aphuei.fsf@gnus.org> <837dcex6ub.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21960"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eric@ericabrahamsen.net, larsi@gnus.org, emacs-devel@gnu.org, cesar.mena@gmail.com, rms@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 21:17:02 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 1mvPqg-0005Tw-DY for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 21:17:02 +0100 Original-Received: from localhost ([::1]:50322 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvPqf-0006sx-9V for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 15:17:01 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvPoo-0005Be-3z for emacs-devel@gnu.org; Thu, 09 Dec 2021 15:15:07 -0500 Original-Received: from [2001:470:142:3::e] (port=56738 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 1mvPol-0001WK-Oz; Thu, 09 Dec 2021 15:15:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dd+bieAA6MJGOQDw6Av+IO5CUTwIaYox6Z7wIqqUUGU=; b=G7+Rh24dvqFr KHk56Vl3ULLEP+mccD/PmrytooeiWEzsIpHveBZhaUOHzh/6bw7gff/paLRfQJoyRtJjPFrSbSf9D 6FVzOnsuGRApThf+xHtJexmGFzmQwQghc7DCE9ORV9XiDvkgTWeSlUC/RNaVIi6sSOs9OCANcCS0l YLA/0Hh8PAn8KtFCDsAljy/3I0akxSumQ5kypCDlz3rGMxZWT16Gn7mv26VyUgngFQQx6RMcInfTC Fj4qveSeyIwaalok7eAUmy/+w8/p73tsYtENblKTtEd8fIfhNBhHTZ5Jf1TlDm0+4VwgfOiI3TEoP NwyF1J9cyELv81Ta05HlRg==; Original-Received: from [87.69.77.57] (port=1228 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 1mvPoe-0005Oa-Bk; Thu, 09 Dec 2021 15:14:56 -0500 In-Reply-To: (message from Pip Cet on Thu, 9 Dec 2021 19:46:22 +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:281541 Archived-At: > From: Pip Cet > Date: Thu, 9 Dec 2021 19:46:22 +0000 > Cc: larsi@gnus.org, eric@ericabrahamsen.net, cesar.mena@gmail.com, rms@gnu.org, > emacs-devel@gnu.org > > > > The proposal is to have Emacs store some user data in some binary > > > format > > > > No, the proposal is to have Emacs _capable_ of storing data in a DB. > > See, apparently, not even that is made clear in the message. What else can be meant by a proposal to allow Emacs to create and access databases? There's no other reasonable way of reading that message. > However, having reread it, I maintain that Lars is indeed proposing to > have Emacs store etc. etc. I just don't see another way of reading it. Of course, if we give Emacs such a capability, it's to let it be capable of storing etc. What else did you expect? It's still just a capability, and any of its use in core warrants a separate discussion. At that time, if you think some use of this capability is not the best idea, please voice your opinions and propose alternatives you think are better. But objecting to a capability as such makes no sense to me, because it makes Emacs a more powerful platform. > > > that cannot be readily inspected, diffed, backed up, > > > version-controlled, shared, altered, or understood. (Or archived, > > > published, indexed, checksummed, ...) > > > > That's incorrect: tools exist that can browse sqlite databases and > > compare them. > > "readily". Which means what exactly? We use a tool, Diff, to compare text files. We use another tool, sqldiff, to compare databases. Where's the crucial difference that justifies rejecting the _capability_ of working with a DB? > > No, the benefit is to be able to store and retrieve data from a > > persistent DB. Python has it, Lua has it, JS has it, so why > > shouldn't Emacs be able to have it? > > That's not the proposal as I read it. You are arguing against specific uses of this capability that no one has yet seriously put on the table. Please wait until such a discussion actually happens, and propose the alternatives for that specific application of the DB capabilities. Talking about it now is too soon, and is also not efficient, because there's no specific concrete application we can discuss, and so the arguments tend to be semi-philosophical, something that doesn't facilitate useful discussions. > > If you are right, then this capability will remain largely unused. > > Like Lisp threads, for example. Let's talk in a couple of years. > > I don't believe in the infinite wisdom of package maintainers, > particularly when it comes to not doing a technically nifty thing that > happens to have actual side effects. And you think by refusing to have this capability in the core we will be able to prevent that? > > > And we need to be careful about introducing this "as an option", of > > > course, because that means two versions of many packages' core code > > > need to be maintained, only one of which will be tested by users who > > > have not had the time to customize the defaults. > > > > No, it means the packages that need such a capability will _require_ > > Emacs with sqlite support. Like any package that needs to display > > SVG requires Emacs with librsvg support, for example. > > Same effect: users will be forced to have to deal with binary files, > because they either don't have the option not to use them or won't > notice they're using them until it's too late. Let's avoid that. There's nothing wrong with binary files, IMO. E.g., Git (and any modern VCS) uses them. Heck, even Emacs does: what are the *.elc files? But if I'm wrong, users will complain, and we all learn a lesson. > > Your file system doesn't actually erase the data from the disk, > > either, as you probably well know. That doesn't mean we cannot use > > disk I/O in Emacs. > > I think the danger of people accidentally sharing a file without > considering what invisible extra information it might contain > (particularly if there's no good reason for such invisible information > to be present in the first place) is MUCH larger than that of people > deliberately sharing an image of their decrypted file system volume, > expecting only current file system-visible content to be preserved. > > The first happens on a regular basis with blacked-out PDFs, Microsoft > Word and Microsoft Excel documents, and other such abominations. I've > not heard of the latter happening on any significant scale. It happens all the time on any multi-user system. > > I don't see any reason for these precautions. We never did that for > > any other optional feature that requires an optional library. > > You're right that features of Emacs were usually introduced by turning > them on by default, then breaking the "off" option because no one used > it anymore (see pdumper). I don't think that this approach has been > hugely successful, certainly not enough to justify repeating that > mistake in this case. I disagree with your assessments, and I think I have more experience to base that on than you do.