Re: sqlite3

[Alexandre Garreau]

Le merkredo, 15-a de decembro 2021 3-a horo kaj 18:53 CET, vous avez écrit 
:
> > What about having an intermediary abstraction for persistent stores in
> > general, and on top of that multisession variables?
> 
> I think Lars’ multisession variable is basically a strict subset of
> persistent store, and can be implemented with almost trivial wrappers
> if a persistent store interface is presented.

No, from what I understood multisession *is* not a store (although it 
*uses* one (or two, now)) but an implementation of persistent variables.

Iiuc it doesn’t expose a stable abstraction layer for a kv-store, right?

> So if we do have a
> persistent store interface, the multisession.el interface is
> unnecessary. A more high-level/transparent persistent variable
> interface, instead, is probably more desired.

Why don’t you hack multisession so that it includes a such layer, between 
the current highest-level interface, the choice between sqlite/files? even 
before that, you could add your incremental-log-store to them, and also, 
why not, at least for benchmark sake, a store where one file contains 
everything such as custom.el

> My plan, store.el + persist.el, follows exactly this direction. It seems
> that the Emacs maintainers are unwilling to include them in place of
> what they currently have, however, so guess we have to put it on Elpa
> first.

apparently they already have an implementation for that, maybe you should 
work with theirs? at least it would advance

I see no reason why ppl would use your implementation, even if it’s more 
richly designed, if it doesn’t provide something that’s very new and not 
already present.  I find your incremental store interesting but not 
appealing, while your abstraction still doesn’t allow using sqlite as one 
of its backends.