Re: sqlite3

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> 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.