Re: sqlite3

[Qiantan Hong]

> No, from what I understood multisession *is* not a store (although it 
> *uses* one (or two, now)) but an implementation of persistent variables.
It’s closer to a kv store than persistent variables. As I mentioned in an
earlier message, kv store and persistent variables themselves are close,
but in multisession.el case, it’s closer to key value store.
(defmacro (multisession-value symbol)
  `(store-get ‘,symbol multisession-global-store))
Persistent variable (in the context of my proposal) is something more 
transparent,
that works without the need to wrap (some-accessor symbol) at every places.
Namely, they works exactly like normal variables, just the value cell is
preserved across session.
> Iiuc it doesn’t expose a stable abstraction layer for a kv-store, right?
Yes.
>> 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
I already have such a layer, if you look at store.el (not sure if you’ve 
already, but just
let me paste the link here)
https://code.librehq.com/qhong/store.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
The problem is not about implementation, it’s about interface.
Lars say the multisession.el interface will not change.
> I see no reason why ppl would use your implementation,
I’m not pushing my implementation, I’m pushing my interface.
From the context I infer that you haven’t look at store.el,
so I guess things will become clear after you look at it.
> 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.
The abstraction apparently do allow.