Should Message-Ids become first-class Gnus objects?

Should Message-Ids become first-class Gnus objects?

[Raja R Harinath]

Hi,

I had a few thoughts about the role of message-ids inside Gnus.

There are many lists of Message-Ids that duplicate information.  For
eg., `gnus-dup' maintains a list and an obarray of message-ids already
seen.  `gnus-gl' maintains a list of message-ids rated.  All these are
separate obarrays, and duplicate the message-id string.

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.

Things like the following could be done:

Property	    Value		Meaning/Use
--------	    -----		-----------
:seen		(next . prev)	The message has been seen.  The next
				 and prev form a doubly-linked list of
				 symbols in the order seen.  This can be
				 used by `gnus-dup'.  No need to store
				 `gnus-dup-list' and `gnus-dup-hashtb'.

:refs-to	(r1 r2 ...)	The References: header

:has-refs-from	(c1 c2 ...)	Inverse of the References: header.
				 To store list of articles that refer to
				 this message-id.  Can be used to find
				 list of replies to an article, for one.
				 (this is on the Gnus todo list)

:where		((ng1 . art1)	This can be used to list what groups
		 (ng2 . art2)    this message occurs in.  The Xref:
		 ...)            header + local copies.  Used with the 
				 prev two properties, can be used to
				 follow threads across newsgroups.

:gl-prediction	(score l . h)	This can be used to store predictions	
				 obtained from the GroupLens BBB

:gl-rating	(score . time)	This can be used for storing user
				 GroupLens ratings

Using the dup-list maintenance as an example:

gnus-dup-enter-articles would do in a loop

  (put (setq cur (intern "msg-id" gnus-msg-id-hashtb)) :seen (prev . nil))
  (setcdr (get prev :seen) cur)		; ?? is a put reqd or is this ok
  (setq prev cur)

gnus-dup-drop would do

  (setq links (get cur :seen))
  (setq prev (car links)
        next (cdr links))
  (setcdr (get prev :seen) next)
  (setcar (get next :seen) prev)
  (put cur :seen nil)

and gnus-dup-save would do

  ... skip (total-seen - gnus-dup-list-lgth) messages ...
  (while (setq cur (cdr (get cur :seen))) 
      (insert (symbol-name cur)))

Your comments ...

- Hari

-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Should Message-Ids become first-class Gnus objects?

[Lars Magne Ingebrigtsen]

Raja R Harinath <harinath@cs.umn.edu> writes:

> There are many lists of Message-Ids that duplicate information.  For
> eg., `gnus-dup' maintains a list and an obarray of message-ids already
> seen.  `gnus-gl' maintains a list of message-ids rated.  All these are
> separate obarrays, and duplicate the message-id string.
> 
> 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.

Well, all the different functions use a different subset of
Message-IDs, and the Message-IDs live for a shorter or longer time.  I
think trying to make One Unified Message-ID thingie could be quite
difficult.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen