From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/26161 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.gnus.general Subject: New approach to grouping/backend/marking - good or bad idea? Date: 03 Nov 1999 18:42:12 -0600 Sender: owner-ding@hpc.uh.edu Message-ID: <87k8nzgk9n.fsf@raven.localnet> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035163423 17965 80.91.224.250 (21 Oct 2002 01:23:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:23:43 +0000 (UTC) Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA02373 for ; Wed, 3 Nov 1999 19:42:48 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id SAB19482; Wed, 3 Nov 1999 18:42:44 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 03 Nov 1999 18:42:55 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id SAA26963 for ; Wed, 3 Nov 1999 18:42:45 -0600 (CST) Original-Received: from omen.dhis.org (mail@cs2868-22.austin.rr.com [24.28.68.22]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA02367 for ; Wed, 3 Nov 1999 19:42:14 -0500 (EST) Original-Received: from raven.localnet ([192.168.1.7] ident=mail) by omen.dhis.org with esmtp (Exim 3.03 #1 (Debian)) id 11jAyi-0003oQ-00 for ; Wed, 03 Nov 1999 18:42:12 -0600 Original-Received: from rlb by raven.localnet with local (Exim 3.03 #1 (Debian)) id 11jAyi-0002ln-00 for ; Wed, 03 Nov 1999 18:42:12 -0600 Original-To: ding@gnus.org Original-Lines: 71 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.4 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:26161 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:26161 These may very well just be "bad ideas(TM)", but, after running them by another Gnus notable and not getting "laughed out of the room", I'd like to run them by whoever else will listen to see what they think. Aside from possibly being just wrongheaded, these ideas might also be completely unimplementable. Since I don't have enough experience with the Gnus codebase to evaluate if that's true easily, I figured I'd ask those who do. There are two bits here. The bit that I feel pretty sure is a good idea is that of adding "message keywords" to Gnus. Imagine that you can (either manually, or via automatic means like the split process), add arbitrary keywords to articles. These keywords could then be used for whatever you like, but I could imeediately see a use for them in searches, narrows, etc. This would easily eliminate all the arguments that keep me from being happy just using total-expire. For example, I would like to use a "todo" keyword, and attach that to articles that I need to do something about. Then I could enter a group and do a "/ k todo" or whatever, and see all those articles. I could even see extending the system to support both user and system level keywords (i.e. separate keyword namespaces). The system level keywords could be used to implement a more flexible "marking" system. Things like read, expired, killed, could just become keywords. This would mean that you could easily support something like allowing an article to have two marks, and, with a little more work, the user could decide which of their kewords receive the "dormant behavior", the "ticked behavior", etc. I've also been toying with a the idea of a much more radical variation on the same theme. What if the mailer stored every message *only once* in a guaranteed uniquely named file (across the entire backend), and then used keywords (instead of physical placement in the filesystem) to indicate groups? In such a setup, a "group" could just become the set of articles which matches a given keyword search criteria, crossposting an article would just means adding more keywords to it, hardlinks wouldn't be needed for efficiency, deciding when to delete an article would be (as it should be) a completely orthogonal issue from deciding which groups it is in, and, finally, since you have a guaranteed unique ID for every article, you could easily use those article ID's like URLs to refer back to important mail from other files. You could safely say things in your todo list like * Make sure to implement the frobbing mentioned in in * Don't forget the devices for the ritual and then access these articles instantly via a nifty gnus-jump-to-article function that worked from any emacs buffer. There are also a couple of system level advantages to using this approach. One minor one is that you could use subdirectories automagically for efficiency. For example, you could store article as: Mail/storage/000/000/000/023 This way no directory would ever have more than 999 files. As compared to the current system where you can end up with thousands of files in a single group, this would probably be a performance win, though it's arguably one that would really be better solved at the OS level. Is this interesting? Would it be too much work for too little gain? Thanks -- Rob Browning PGP=E80E0D04F521A094 532B97F5D64E3930