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, 08 Dec 2021 20:57:32 +0200 Message-ID: <837dcex6ub.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15994"; 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 Wed Dec 08 19:58:57 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 1mv29Y-0003qx-Hc for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Dec 2021 19:58:56 +0100 Original-Received: from localhost ([::1]:43868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mv29X-0004X0-HT for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Dec 2021 13:58:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv28c-0002XO-D3 for emacs-devel@gnu.org; Wed, 08 Dec 2021 13:57:58 -0500 Original-Received: from [2001:470:142:3::e] (port=41930 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 1mv28b-0002RN-M3; Wed, 08 Dec 2021 13:57:57 -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=FHrAFPGklkF6svZn2Nixy3uLaUSdVftoZJEA6aEs2mo=; b=GnMGtd/6NGZx ypa4lWLJ/F/04Xb5hejsxswOVAtjv/eog1fQtDqHnu5X/1cRySskT/0ZFMlXkcpxA1b2cX5k67oL0 Qh6J+cEhqijRZdwpBmPJ9vLq5+YfYEELjXP/7KH6e3G532qv8BdURREvJpHpmBWGPa4fqIpRe+p44 9cDsQUQO7U2cdoAic9ZK4T0b5gAZB5HQYdyJ30SWqBXWowpZHqSQ3vkdqoflQ8hGhcTPrEjBL3fjw j1B8yC/7hFSyPtRG755zzfISN2R6ytjlzjtB3s/W9pIXv8fZbk/oeI6sA0lGVjWBb6rGl4RDOHHqm q+yewkvuPFLqcLJIC6gn9A==; Original-Received: from [87.69.77.57] (port=3381 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 1mv28V-0006da-Er; Wed, 08 Dec 2021 13:57:51 -0500 In-Reply-To: (message from Pip Cet on Wed, 8 Dec 2021 18:36:24 +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:281376 Archived-At: > From: Pip Cet > Date: Wed, 8 Dec 2021 18:36:24 +0000 > Cc: eric@ericabrahamsen.net, cesar mena , > Richard Stallman , emacs-devel@gnu.org > > > Just read the first one. It explains everything. > > I disagree, FWIW. There's very little in that message that goes beyond > "let's use sqlite!" Why is that a problem? > 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. We didn't yet seriously discuss whether some core features will actually use that, and if so, which ones. > 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. > Those are huge disadvantages. The benefits are not clear to me at all, > but they seem to revolve around the time it takes for an interrupted > or terminated session to restart? 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? > I don't think there are any applications for which the trade off (gain > some performance; lose some user freedom) is worth it, but even if > there are, we should look harder at alternatives which allow us to > gain similar amounts of performance without littering unsuspecting > users' .emacs.ds with binary-only files. If you are right, then this capability will remain largely unused. Like Lisp threads, for example. Let's talk in a couple of years. > 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. > I've tested a little and at least in those initial tests, sqlite seems > to actually delete data from sqlite files when the corresponding rows > are deleted, but I'd like to mention this explicitly because I'm not > sure there's actually a guarantee of it in place: if sqlite ever keeps > storing data that the user thought they deleted, that makes it > unsuitable for storing the kind of data I would expect in .emacs.d. 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. > Of course, none of this is meant to stop people experimenting in any > way, but I don't see any package that should realistically be able to > make use of it without an opt-in option and probably an extra warning. I don't see any reason for these precautions. We never did that for any other optional feature that requires an optional library.