From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8065 Path: main.gmane.org!not-for-mail From: Raja R Harinath Newsgroups: gmane.emacs.gnus.general Subject: Should Message-Ids become first-class Gnus objects? Date: 26 Sep 1996 18:51:15 -0500 Sender: harinath@cs.umn.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.87) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035148288 9958 80.91.224.250 (20 Oct 2002 21:11:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:11:28 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.6/8.6.9) with SMTP id RAA00093 for ; Thu, 26 Sep 1996 17:09:24 -0700 Original-Received: from mail.cs.umn.edu (mail.cs.umn.edu [128.101.149.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 27 Sep 1996 01:51:20 +0200 Original-Received: from femto.cs.umn.edu (harinath@femto.cs.umn.edu [128.101.224.13]) by mail.cs.umn.edu (8.7.5/8.7.3) with ESMTP id SAA18123 for ; Thu, 26 Sep 1996 18:51:19 -0500 (CDT) Original-Received: (harinath@localhost) by femto.cs.umn.edu (8.6.12/8.6.12) id SAA10843; Thu, 26 Sep 1996 18:51:16 -0500 Original-To: ding@ifi.uio.no Original-Lines: 74 X-Mailer: Red Gnus v0.42/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:8065 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8065 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