From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/11329 Path: main.gmane.org!not-for-mail From: Paul Franklin Newsgroups: gmane.emacs.gnus.general Subject: Re: TODO idea: Date: 10 Jun 1997 10:52:36 -0700 Sender: paul@cs.washington.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035151056 29620 80.91.224.250 (20 Oct 2002 21:57:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:57:36 +0000 (UTC) Return-Path: Original-Received: from sandy.calag.com (root@sandy [206.190.83.128]) by altair.xemacs.org (8.8.5/8.8.5) with ESMTP id LAA29226 for ; Tue, 10 Jun 1997 11:43:30 -0700 Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by sandy.calag.com (8.8.5/8.8.5) with ESMTP id LAA27493 for ; Tue, 10 Jun 1997 11:43:45 -0700 Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by xemacs.org (8.8.5/8.8.5) with SMTP id NAA00940 for ; Tue, 10 Jun 1997 13:43:06 -0500 (CDT) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 10 Jun 1997 19:52:41 +0200 Original-Received: (qmail 19836 invoked by uid 504); 10 Jun 1997 17:52:39 -0000 Original-Received: (qmail 19833 invoked from network); 10 Jun 1997 17:52:39 -0000 Original-Received: from teapotdome.cs.washington.edu (128.95.1.55) by claymore.vcinet.com with SMTP; 10 Jun 1997 17:52:39 -0000 Original-Received: (paul@localhost) by teapotdome.cs.washington.edu (8.6.12/7.2ws+) id KAA24892; Tue, 10 Jun 1997 10:52:37 -0700 Original-To: ding@gnus.org In-Reply-To: Jason R Mastaler's message of 09 Jun 1997 20:58:20 -0600 X-Mailer: Gnus v5.4.39/Emacs 19.34 Original-Lines: 37 Original-Xref: altair.xemacs.org dgnus-list:1719 Xref: main.gmane.org gmane.emacs.gnus.general:11329 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:11329 >>>>> Jason R. Mastaler writes: > Is it necessary to write a new backend? Why not just code the unseen > sequences functionality into nnmh and optionally, nnml? Why code the unseen functionality? Since nnmh isn't quite mh in that it can't handle asynchronous delivery, there isn't any current code (AFAIK) which adds messages to nnmh or nnml folders and updates the unseen sequence. So, there needs to be another way. One way would be to have a file similar to the active file which the mail delivery system writes to; nnml would only read it and update its own active file based on what it reads. The mail delivery system would still have to lock it, but nnml no longer cares how. The other way is the method I keep making noises about implementing but never get my act in gear and implement it. Let the messages be delivered directly into nnml folders based on the active file. Then keep key headers (for the overview) and add one saying what folder & nessage number the message was placed at to the normal locked mail spool. So now our old trusted mail spool only has headers needed for overview generation instead of the entire message, and gnus only has to write active and overview files, not the contents of every message. (Then all you do is cache the overview lines until group entry instead of writing them immediately, and writing the unseen handler becomes easy.) Either one of these requires both gnus/nnml and the mail deliverer to back off if it selects a folder's next message number and creating the file fails, as that means the other just grabbed it. One of these days... --Paul