Re: persistent data feature

[Qiantan Hong]

> I think the Gnus registry (info "(gnus) The Gnus Registry") is a good
> example.  Mine is 3.6 MB but only because I've set
> `gnus-registry-max-entries' to 10000 and `gnus-registry-track-extra' to
> nil because I've basically only ever used it to be able to refer to an
> article's parent.
> 
> There should be no reason to cap its number of entries or the number of
> things it tracks.  By default it would also track sender, subject, and
> recipients of messages.  I guess that would easily quadruple its size
> for me.
I agree the number should not be restricted. I will try to implement
split bucketing in probably the next^2 revision of resist! then.

There’s still a technical question unanswered. If I’m to use multiple
files to store one kv store, is it better to let user supply a directory,
or let user supply a filename and we add suffixes?

> I also think the Gnus registry is an example of where a DB with a
> specific schema and queries would make sense instead of some persistent
> variable.  There's no value in having that huge pile of hash-maps in
> memory if I just want to, e.g., move the current mail into the folder
> where its parent already resides.
I think in your case, even if the db quadruples, it’s still < 20MB in
textual representation and probably much smaller when resided
in the heap. It’s still a pretty long way to go before memory-residence
become problematic.