Re: sqlite3

[Eric Abrahamsen]

cesar mena <cesar.mena@gmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> I think many user experience things in Emacs would be better if Emacs
>>> remembered more.
>>>
>>> The bigger systems don't have this problem -- Gnus needs a large
>>> .newsrc.eld file, and it maintains that.
>>
>> A plea from the heart: Gnus also needs a better data store, and sqlite3
>> is the answer to that need. The .newsrc.eld format is not okay.
>
> Unclear about this comment.  Lars specifically stated that this is for
> things that fall in between tiny (use customize) and bigger (gnus etc ...):
>
>    The bigger systems don't have this problem -- Gnus needs a large
>    .newsrc.eld file, and it maintains that.
>
>    The tiny things don't really have this problem, either: You save options
>    with `customize-save-variable', and that fine.
>
> Are you proposing a move to sqlite3 for .newsrc.eld?

Well, Lars is the Gnus maintainer, not me, so all I can do is propose!
But yes I am, though only for group marks. Right now .newsrc.eld
combines concerns: it saves variables such as `gnus-server-alist' and
all the topic stuff that would be better saved as customization options
(or saved in a separate file, using the customization machinery). It
also saves group parameters, right next to the marks.

I've long felt that the data above should be kept in a separate file,
that's expected to be user-readable and even (to a certain extent)
user-editable. It's *mostly* set through Gnus' own interface, but you
could certainly tweak it by hand if you wanted. Marks, however, are
meaningless to read and practically un-editable. Their presence in
.newsrc.eld makes the file slow to open and scroll, and has given rise
to a meme of "don't touch the .newsrc.eld file, you'll destroy
everything". That in itself is a sign that we're using the wrong format
for this data.

In terms raised elsewhere in the thread: the variable data is
user-editable, and should be version-controllable. The mark data is not
realistically editable through any interface but Gnus's own UI, and is
not appropriate for version control. Ergo, it should go in its own file,
and a sqlite file would be a perfect choice for that.

It seems likely that *requiring* sqlite support is a non-starter, so
this would only be an option. But ideally I'd like the options to be 1)
keep the marks in their own text file, that contains nothing but group
names -> mark info; 2) keep the marks in recutils; 3) keep the marks in
sqlite; 4) write your own mark-saving backend.

That's it!

Eric