Re: persistent data feature

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> You'll get a slower and messier interface.  If you're (optionally)
> storing the data in different data files, which ones has precedence?

I disagree with the messier part: that is purely an implementation
detail, and no such implementation exists yet.

But for uses such as storing a list of recently used Emoji, is a "slower
interface" really such an important downside?  Especially since the list
of recently used Emoji will be stored in a ring of some arbitrary (but
small) size.

I suspect that the use-cases which require storing a large amount of
data (such as the Gnus registry) will generally opt to use sqlite3
directly, instead of going through the "sticky value" system (which
involves printing Lisp data to a string, storing it as a string in the
database, and reading it back again).

> Will all these backends have the same semantics wrt. concurrent updates
> from different Emacs instances?

We could either make that undefined behaviour (the easy way out), or
design a locking mechanism for the text-based backend.  Perhaps the
existing file locking mechanism could be used for this.

> Will they offer the same introspection opportunities (like "delete all
> stored data that refer to 'foo'"?)

Sure, why not?  Since SQLite does not know about Lisp objects, I don't
see what advantage it can have WRT introspecting the contents of Lisp
objects.

> I won't be adding any other backends for this.

What if someone else does?  Are patches welcome?