Re: sqlite3

[Qiantan Hong]

> On Dec 9, 2021, at 8:45 PM, Michael Heerdegen <michael_heerdegen@web.de> 
> wrote:
> 
> It allows to attach additional information to messages, like user
> defined marks or anything else.  Allows to jump to parent messages that
> are not part of the current group.  Such things.  Gnus then knows about
> all your messages and where they are.
Thanks, I’ve read through gnus-registry.el and it seems to use
only a few of the functions from registry.el
(mostly registry-lookup-secondary, registry-insert and registry-delete),
which seems well suited to be implemented by a general key value store.

Is there anything we want to improve from the current implementation?
Resist! will eliminate the need of explicitly saving the registry, but
is loading the registry currently considered a bottleneck?

> On Dec 9, 2021, at 10:23 PM, larsi@gnus.org wrote:
> 
>> What if someone else does?  Are patches welcome?
> 
> Sure, if they handle the semantics in a nice enough way.  (I.e., not
> making it slower, have the same concurrency guarantees, allow the same
> storage browsing, etc.)
Resist! will handle the concurrency guarantee. 

Performance will be no slower than current implementation, of course. 
IDK if load is considered a bottleneck, but if so I can implement split 
bucketing which will should make the maximum overall pause time comparable 
to an SQLite3 implementation.

As for storage browsing, any tool gnus provides for now should work.
If there’s to be a database editor package in the future, I wonder if
said package can support browser Emacs Lisp image.

> On Dec 10, 2021, at 12:12 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> But the objections explicitly sounded like they were against having
> the DB access capabilities within Emacs.  At least one participant
> explicitly said so.  Which is what I criticized from my POV as one of
> the Emacs maintainers -- resisting to addition of a useful capability
> doesn't make sense.
I was and am opposing “using” databases. Maybe the expression is
awfully ambiguous, I apologize — I might not have known what I really mean
before others point out there’re two completely separate issues here.
ofc I don’t oppose adding SQLite3 support for a SQLite3 browsing/editing
package, what I’m resisting is the use of SQLite3 in Emacs Lisp applications
whose application domain has nothing to do with SQLite3 and deserve
pure lisp implementation.

Best,
Qiantan