Re: sqlite3

[Eric Abrahamsen]

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

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> 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.
>
> Yes, it's a bit of a big hammer. 
>
>>> It's a bit much, but I don't think those bits can be usefully separated
>>> out.  But things like `gnus-save-duplicate-list' (which goes to a
>>> separate, ad-hoc file) would fit well as a simple persistent variable.
>>
>> If `gnus-newsrc-alist' were saved as-is, but *without* the mark data,
>> that mark data could be pulled out of a separate storage backend at
>> startup time, with a simple group-name->mark-data mapping. The
>> .newsrc.eld file could otherwise remain the same.
>
> One can edit flags through G p in the topic buffer; that interface would
> need to be preserved.  Who knows what other secrets lurk in there.

My proposal would only affect the save and load routines (zip and unzip
data), in-session behavior wouldn't change.

>> But Qiantan's message reminded me that this proposal is actually a Gnus
>> issue, not a sqlite issue, and shouldn't clog up this thread. I'll keep
>> this for later!
>
> Yes, but in the end separating flags from .newsrc.eld is not for the
> faint of heart, and I am not sure I see the benefits. 
>
> Like you said, for later.

I have any number of pie-in-the-sky ideas for Gnus. If I get around to
implementing half of them, I'll consider it a success :)