From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8068 Path: main.gmane.org!not-for-mail From: Usenet news Newsgroups: gmane.emacs.gnus.general Subject: Re: Message buffers associated with files? Date: Fri, 27 Sep 1996 07:23:25 +0200 (MET DST) Sender: paul@fester.cs.washington.edu Message-ID: <199609270523.HAA25994@sunsite.auc.dk> References: <199609172045.PAA24878@mordor.rsn.hp.com> ; Thu, 26 Sep 1996 22:39:02 -0700 Original-Received: from sunsite.auc.dk (news@sunsite.auc.dk [130.225.51.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 27 Sep 1996 07:23:27 +0200 Original-Received: (from news@localhost) by sunsite.auc.dk (8.7.5/8.7.3) id HAA25994 for ding@ifi.uio.no; Fri, 27 Sep 1996 07:23:25 +0200 (MET DST) Original-To: ding@ifi.uio.no Original-Newsgroups: emacs.ding Xref: main.gmane.org gmane.emacs.gnus.general:8068 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8068 .com> From: Paul Franklin Date: 26 Sep 1996 22:23:22 -0700 Message-ID: Organization: Computer Science, U of Washington, Seattle, WA, USA Lines: 66 X-Newsreader: Red Gnus v0.34/Emacs 19.34 Path: fester.cs.washington.edu NNTP-Posting-Host: fester.cs.washington.edu >>>>> Lars Magne Ingebrigtsen writes: > Well -- manual pages aren't particularly message-like. New manual > pages seldom appear, and it isn't really interesting to mark read > manual pages in any way, so I don't think an nnman backend would make > much sense. This is the problem I ran into when I was contemplating writing nngnats, and all of the time I had slated to actually write it went into discovering how these models don't match. :) (And now I've left my summer job and don't use nngnats anymore. But now I'm really wanting imap stuff again. Sigh.) The issues with nngnats are even more difficult--files change, and you want to notice when they do. Not only can the content change, but the status can change as well--essentially, the back end wants to keep track of some of the flags. And some files you want to see again whenever they change, while others you don't want to see again. This could be done through scoring, but the ideal thing would be to redefine dormancy as articles which magically become either unread or ticked when they change. (This works well with gnats, since you should never have followups; you just keep adding to the same document.) So here's my wish list for backend capabilities needed by nngnats (which should be a superset of those needed for a nice nnman): * Backends can affect the marks of articles. Hmm. Looks like this is now possible by coding nngnats-request-update-info. This would be the time to awake dormant articles when they've changed. * Backends can contribute additional fields. Users can limit by these fields, possibly through a special '/' command which prompts you for a backend-specific field name. Users can also score on these fields. (For nngnats, this would include responsible person, severity, priority, ...) * Backends can have persistent, internal state. For nngnats, this would be the last mod date of the gnats report, and possibly 1-2 other things so the files don't have to be scanned every time. (Or maybe this should go into files in a directory specified by a server parameter. It can't go into a gnats or man dir, since they're shared dirs.) For nnman, this would be the article numbers of man pages. (Hmm. Pretty soon, we'll have a .gnus directory for all of this stuff.) * Backends should be able to reject incorrectly-formatted messages in -request-replace-article and -request-accept-article, probably via a return value. This would allow someone to submit or edit problem reports from gnus with appropriate checks in place. * Backends should be able to lock files for editing, if that's necessary. (I'm not sure if nngnats actually needs it, but it seems really useful.) Hmm. We're closer than I thought. One has been addressed, and one has an alternative I hadn't thought of earlier which probably is better anyways. (For the record, someone else wanted nngnats groups to be basically query parameters for querypr. My personal opinion is that gnus' scoring and limiting mechanisms can deal with this quite adequately. And I wanted to read the gnats list of bug reports directly, so I could base the active file on it.) --Paul