[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sqlite3

From: Qiantan Hong
Subject: Re: sqlite3
Date: Sun, 12 Dec 2021 06:58:34 +0000

> On Dec 11, 2021, at 10:50 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Qiantan Hong <qhong@mit.edu> writes:
>> I’ve read through multisession, it seems that all of multisession.el,
>> the current persist.el on Elpa, and my resist!.el & proposal that
>> would move into persist.el namespace, have very similar aim.
> [...]
>> Are you willing to proceed in this direction?
> The interface will stay as it is in multisession.el, I think.
> (But the name might change if somebody comes up with a better name for
> "multisession" (that's not taken).  "Persistant" is taken, and "persist"
> seems awkward.)
Seems that namespace is a common problem for us.
I’ve discussed with a few other people and am currently
settling on the option to take the persist namespace from
an existing package. But sure, new proposals are welcomed.

I’m thinking of rather not exposing multisession.el directly,
but instead use it as a backend for store.el.
The interface just need to be changed a little bit,
(multisession-value OBJECT) => (store-get OBJECT (STORE sqlite3-store))
(multisession--set-value OBJECT VALUE) => (store-put OBJECT VALUE (STORE 
Basically, just add the database as an parameter so user can use any databases,
and define the functions as method of store-* instead.

Then, <whatever-name-we-choose-for-persistent-variable>-* will accommodate
my transparent persistent variable interfaces, and backward compatibility for
what’s already in persist.el Elpa package.
The user can configure them to use the sqlite3 backend taken from 
or other backends.

If you agree, I could make a patch that implements the above changes.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]