Re: [PATCH] Two issues with the gnus-registry

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 08 Nov 2014 16:39:48 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 
>
> EA> So unless I'm really missing something, my proposal is:
>
> EA> 1. Only provide one limit: max-size.
> EA> 2. Allow customization of prune-factor.
>
> EA> That seems like all the customization you'd need. Cap the size, and
> EA> provide a reasonable control of how often the registry gets pruned.
>
> OK. I am afraid I made the whole thing too complicated and it took
> another set of eyes to recognize it.  Thanks for that, and the fixes.
>
> Please go ahead and apply any changes you have in mind. I am sure no one
> is tuning soft/hard pruning. Simpler is definitely better.

Cool, mostly I'm glad I'm not missing something -- I discovered over
several days of staring at it that I'm pretty bad at mental math.

> EA> That would require a change in the object signature, which would mean
> EA> some extra handling code for "upgrading". But once we're doing that, we
> EA> could also take the opportunity to add :prune-function and
> EA> :sort-function slots on the base registry object, which would be
> EA> nice. We could even change the default store filename from its "eioio"
> EA> extension to "eieio". :)
>
> Yeah, I remember that bug report about the extension of the database
> file, if we're upgrading anyway... It's a good chance to batch these
> changes.

Okay. I guess this will require some (slightly unfortunate) one-off code
that will have to live in the codebase for quite some time, but I'll try
to make it as unobtrusive as possible, perhaps using advice. Maybe it
should even go in a separate file?

If there's something else you've been meaning to tweak regarding the
database format, let me know and let's get it done! You mentioned
wanting to provide alternate data storage options: I doubt I'll be of
much help there, but maybe we could leave a stub in place so that future
expansions don't require file format changes. It might even make sense
to separate the registry object and its :data store. The persistent
object, as it behaves right now, might look like:

(registry-db "Gnus Registry"
  :file ".gnus.registry.eieio"
  :max-size 50000
  :data (file ".gnus.registry.dat"))

That would probably leave all the flexibility you'd need for future
extensions. 

And... while I'm pulling things out of my rear end, I've also thought it
would be nice if the Gnus registry was actually a subclass of the
registry class. If all the message tracking stuff was done in methods,
it would be very easy for people to make their own special-purpose Gnus
registries.

Anyway, something to think about for the future.

Eric