Re: message registry for Gnus

[Ted Zlatanov <tzz@lifelogs.com>]

On Sat, 01 Feb 2003, harinath@cs.umn.edu wrote:
> See
> 
>   http://article.gmane.org/gmane.emacs.gnus.general/8065
> 
> for some of the possible uses for the registry.  I'm sure the actual
> mechanics suggested there are somewhat bogus.

Wow, you posted that in 1996?  You've been slacking :)

(I'm quoting from the web site, sorry for the weird quoting)

Hari wrote:
| I wonder if using a single message-id hashtb with the other facilities
| being implemented as property get/sets will be a better alternative.         
| This would require a major rearchitecting of Gnus.                           

I think the registry should coexist with everything else.  I want it
to be as flexible as possible.  The properties you mention can be
associated with a message ID through a registry API, sure, but so can
any other properties.

As for the properties themselves (with the understanding that those
would just hook into the registry, without being integral to its
existence):

:seen is not needed as you state, is it?  We only need to store the
actual article number and full group name associated with the message
ID in a property that's a list each time we see the message ID
spooled, copied, or moved.  If there are more than one entries in the
list, the article is duplicated somewhere.  This is sufficient to find
any article's copies by message ID.

:refs-to and :has-refs-from seem to be better off in a separate table
(if articles are nodes in a graph and references are edges - for a
generic graph it's easier to store the edges in a separate table if I
remember my database design)

:where - see :seen above, probably not necessary as we can find where
an article has been copied or moved easily

:gl-prediction and :gl-rating are useful properties in the context of
the GroupLens system, but I think we should move away from the
GroupLens name :)  It's just another kind of scoring, so let's call it
distributed scoring or something like that (the manual talks about a
different kind of distributed scoring with remote score files, but
that's not that different from GroupLans after all).

Ted