Re: sqlite3

[Lars Ingebrigtsen]

Pip Cet <pipcet@gmail.com> writes:

> The proposal is to have Emacs store some user data in some binary
> format that cannot be readily inspected, diffed, backed up,
> version-controlled, shared, altered, or understood. (Or archived,
> published, indexed, checksummed, ...)

The slope is pretty slippery from .emacs to .newsrc.eld to Gnus registry
storage to .sqlite files.

The .emacs file with the Customize settings is usually something a user
can read and edit and diff with some confidence.

The .newsrc.eld file, which is a couple of huge alists with complicated
nesting, is very hard to read, edit or diff, even thought it's "text".
Putting it in VC is meaningless.

The Gnus registry, which is a dumped hash table, can't meaningfully be
read or edited by anybody unless that person is an expert on hash table
representation and what it all means.  And it's not diffable or VC-able
without special software.

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
course) Emacs will come with a mode to inspect and edit these files more
free-form.  They will, in the end, be a lot more editable than a hash
table dump: This mode will allow you to say "delete all values that
refer to 'foo' no matter where it's stored in this file", and that's not
something that's anybody implemented for all these "text" formats that
Emacs uses today.

As for archiving, publishing, indexing or checksumming: Doing that with
an .sqlite file is a lot more meaningful than a file containing a hash
table dump.

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