Re: nnir, gnus-goto-article and such

[Dave Abrahams <dave@boostpro.com>]

on Thu Sep 29 2011, Ted Zlatanov <tzz-AT-lifelogs.com> wrote:

> On Thu, 29 Sep 2011 09:40:54 -0400 Dave Abrahams <dave@boostpro.com> wrote: 
>
> DA> [Aside: it seems like this territory is full of components that
> DA> could in principle be nicely generalized, but whose implementation
> DA> has only been made to work for one specific usage scenario]
>>> 
>>> I can't tell, I was not involved with writing these components.  
>
> DA> IIUC from reading elsewhere you rewrote the registry.
>
> I wrote *registry.el but I was talking about nnir.el, nnregistry.el, and
> other search functionality.  The registry is not a search engine so I
> thought you didn't mean it.  I'm not sure how it could be generalized
> and in what direction--tell me what you think.

Well, it's in the territory, but it's not one of those components.  I
don't have any complaints about the registry itself.  I was referring
more to things like gnus-warp-to-article, which only functions on a
single kind of group, or general usage of the registry, which only
happens in a very few circumstances even though the kind of queries the
registry can answer are all over the place.

>>> At least for the registry I know it's optional so we can't depend on
>>> it.
>
> DA> I'm not sure what "optional" means in this context.  Is Gnus going to
> DA> ship without the registry code?
>
> Users should be able to use every aspect of Gnus without calling
> `gnus-registru-initialize'.  The memory usage of the gnus-registry, if
> we enabled it by default, would be unpleasant for many of our users on
> older or less capable machines.  Thus any general Gnus functionality
> should not depend on the gnus-registry's availability.

Well, here's an example of a missing generalization then.  The registry
provides a general interface for looking up (information about) articles
based on their message IDs.  However, there's only one of them, and it's
persistent.  nnir would only need a small, special-purpose registry for
each of its groups.  Or, maybe better, one registry could be refcounted
and just discarded when you leave the last nnir group if you haven't
initialized the registry in the meantime.  It wouldn't grow if nobody
was putting things in it.

> Furthermore the gnus-registry should be treated as a lossy cache.  If
> you find something useful, great.  But don't rely on it.  That attitude
> lets us expire it more aggressively.  There are "precious" properties
> you can set, so for instance the registry marks are not lost, but from
> our side we can't expect that.

Sorry, don't know what you mean by "our side."  You can't make things
precious programmatically?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com