Re: sqlite3

[Lars Ingebrigtsen]

Pip Cet <pipcet@gmail.com> writes:

> I agree that .newsrc.eld and the Gnus registry, as you describe them,
> have problems that need to be fixed. Making those permanently
> unfixable by switching to a binary-only format seems like a bad idea
> to me, unless there are overwhelming advantages that I'm just failing
> to see so far.

"Need to be fixed"?  They've been like this for three decades now, and
it's amusing how they suddenly "need" to be fixed when they're brought
up as an example for how textual data isn't really a panacea for
editability, diffing, etc.

The Gnus data is edited within Gnus, because editing the data outside of
Gnus will lead to breakage.

>> Putting it in VC is meaningless.
>
> How so? I usually have my home directory under version control, and
> git's xdelta implementation should deal with alists just fine (and
> produce readable output at sub-line granularity)...

It's meaningless because you can't really do anything with that
information.

>> And it's not diffable or VC-able
>> without special software.
>
> Possibly so. That still means you're making problems that are
> currently coincidental fundamentally unfixable.

?

>> An .sqlite file isn't pretending to be user editable in vi, but there's
>> a plethora of software out there do do all things you'd expect, and (of
>
> How much of it is GNU software?

You mean percentage wise?  I don't understand the issue.

>> course) Emacs will come with a mode to inspect and edit these files more
>> free-form.
>
> Indeed, I would have considered it a good idea to introduce such a
> mode well before proposing (as you might or might not have done) that
> random packages start using a new library.

Er...  I should have written a new library to allow editing SQLite files
before starting a discussion about whether Emacs should have in-core
SQLite support.  Check.

> And a checksum that changes with no underlying changes in the data is
> problematic. Usually not a problem with ELisp dumps, but it usually is
> with sqlite files.

There are programs to do all this.

> And, merely as a request, I'd still like to hear a further convincing
> case for all this being necessary in the first place. So far I've
> heard "Gnus" and "emoji favorites". I can't currently use the former
> and the latter is inaccessible to me on multiple levels, so I'm left
> with my "binary junk in .emacs.d" impression of what you're actually
> proposing.

Emacs needs easy, performant access to large data storage, and this
gives us that, and more.  And it's embarrassing that Emacs doesn't have
this already.

(For instance, my imdb mode stashes about 12GB worth of data in sqlite
and is simple and performant.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no