From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/49756 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: message registry for Gnus Date: Sat, 01 Feb 2003 20:30:05 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: owner-ding@hpc.uh.edu Message-ID: References: <4n3cn9i6kq.fsf@lockgroove.bwh.harvard.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1044149005 3701 80.91.224.249 (2 Feb 2003 01:23:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 2 Feb 2003 01:23:25 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18f8qx-0000xZ-00 for ; Sun, 02 Feb 2003 02:23:23 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18f8s4-00012U-00; Sat, 01 Feb 2003 19:24:32 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 01 Feb 2003 19:25:28 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id TAA09282 for ; Sat, 1 Feb 2003 19:25:17 -0600 (CST) Original-Received: (qmail 74544 invoked by alias); 2 Feb 2003 01:24:16 -0000 Original-Received: (qmail 74539 invoked from network); 2 Feb 2003 01:24:15 -0000 Original-Received: from ns1.beld.net (208.229.215.81) by 66.230.238.6 with SMTP; 2 Feb 2003 01:24:15 -0000 Original-Received: from heechee.beld.net (dhcp-0-30-bd-1-93-b1.cpe.beld.net [24.233.67.61]) by ns1.beld.net (Postfix) with ESMTP id 900353B890; Sat, 1 Feb 2003 20:20:52 -0500 (EST) Original-To: Raja R Harinath X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: Raja R Harinath , ding@gnus.org In-Reply-To: (Raja R Harinath's message of "Sat, 01 Feb 2003 18:35:49 -0600") User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:49756 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:49756 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