From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Thu, 9 Dec 2021 19:46:22 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2336"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 20:49:38 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 1mvPQ9-0000Nl-Ny for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 20:49:37 +0100 Original-Received: from localhost ([::1]:55348 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvPQ8-0007Tm-AL for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 14:49:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60158) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvPNu-0005us-BA for emacs-devel@gnu.org; Thu, 09 Dec 2021 14:47:18 -0500 Original-Received: from [2a00:1450:4864:20::231] (port=40525 helo=mail-lj1-x231.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvPNp-0008Jd-GJ; Thu, 09 Dec 2021 14:47:15 -0500 Original-Received: by mail-lj1-x231.google.com with SMTP id u22so10613797lju.7; Thu, 09 Dec 2021 11:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OlqnL8hzrdivR3Fc5sdbHywwnD1IptSWJgIAbl0WLSE=; b=DDNC+Af5FT7twkY+Xb6g41W5mceotAcxPzZwB/xHMs/hxM3szaOfLnpqeq5YG1IcFx C0l9UASSo9N38UcbC1bYZRWWICqohPRxOMQgRUNLtQmsJDKrN/VKnmL4O6wKiyUCVnJZ 2f8bEwStQURdOUtXM0PBlCUeRscwhyCCKeMUy1HmhODjnu36E8Ddhuo+GblNyWNzBO4i pjRag6NNxaxtmNlivZceYIeXDGRUg2qexbPRxOx9KlafTSHYK7iIu8a8UF2NlYDAlAN1 blDze3g45uIypgJQRAm4Ar1/AbI+2IpOU76MYuQ1JaMpxLhm3uiWaDJVJPyNEQwA6Jcw 6kyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OlqnL8hzrdivR3Fc5sdbHywwnD1IptSWJgIAbl0WLSE=; b=zPgaPCIOStXzsOAwEAq3meirf6OZQrHnP1QWfa9uSGipanxxGf9+zZcOlium5hsjit a+HwUVtT9wKOXL15HEwj6Yf1pePCdsOavVBYcXo2STQw+NeY/q5d3+lHN5fd6ss5XWMI 1UY2vcutUPWXESroUHwEG0PttrewZwaOPXF0xUhmfYGotQbhbXfnkVFYMgyj2SeEDDXH WhQgajgrPvmSLRbUteFNRX0+CrGJRwGsHxqOI+taqMQsHqe/LyUUUo4vnHpiS/en4PZy przYNtnytk/w9Oubj3rCYvK2xGWPdcYwxtd9xKPGXIWg1thjPejq4etKzU7rrwDLzRHS vDuQ== X-Gm-Message-State: AOAM530b1wTD8PGh0vUG/HkE/p9RsMuvlF1omMznr6JG9vujg1Oqy2bh +sZg6jB3InScZJ1ZPpeyW5g5pROD0l/YoGFQnuzacZ/gphTFQg== X-Google-Smtp-Source: ABdhPJw/YEBJoz0PwAChNKtQT7NPdMiTDvFXV/l1QcGgBNC3eh8AY2PoFm1lR1Jgt/YevILfRWXJh+LSvMoR1jXbPt4= X-Received: by 2002:a2e:a305:: with SMTP id l5mr8051633lje.100.1639079219459; Thu, 09 Dec 2021 11:46:59 -0800 (PST) In-Reply-To: <837dcex6ub.fsf@gnu.org> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::231 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::231; envelope-from=pipcet@gmail.com; helo=mail-lj1-x231.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, 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:281537 Archived-At: On Wed, Dec 8, 2021 at 6:57 PM Eli Zaretskii wrote: > > 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.sq > > > > I disagree, FWIW. There's very little in that message that goes beyond > > "let's use sqlite!" > > Why is that a problem? Lars said his message explains everything. I say it doesn't. Whether that is a problem or not is up to you. > > 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. 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. > We didn't yet seriously discuss whether some core features will > actually use that, and if so, which ones. I agree that the necessary discussion has not taken place. > > 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". > > 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? That's not the proposal as I read 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. 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 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. > > 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. 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. The former makes it unsuitable for .emacs.d. The latter only makes it important to keep educating people about what file systems do and do not do. > > 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. 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. Pip