From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32904 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: "Fixing up" gnus - (how hard is this?). (was Re: (provide 'nnmaildir)) Date: 19 Oct 2000 20:03:35 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87aec3o3u6.fsf_-_@raven.localnet> <871yxfnlnz.fsf@raven.localnet> <87g0lt9amk.fsf@raven.localnet> <87hf697kba.fsf@raven.localnet> <87bswg1kbt.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 1035169109 22383 80.91.224.250 (21 Oct 2002 02:58:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:58:29 +0000 (UTC) Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id 92A66D0645 for ; Thu, 19 Oct 2000 20:04:51 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id TAB13791; Thu, 19 Oct 2000 19:04:41 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 19 Oct 2000 19:04:02 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id TAA17907 for ; Thu, 19 Oct 2000 19:03:45 -0500 (CDT) Original-Received: from multivac.student.cwru.edu (multivac.STUDENT.CWRU.Edu [129.22.239.69]) by mailhost.sclp.com (Postfix) with SMTP id B6408D0645 for ; Thu, 19 Oct 2000 20:04:03 -0400 (EDT) Original-Received: (qmail 31512 invoked by uid 500); 20 Oct 2000 00:03:58 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org In-Reply-To: Rob Browning's message of "19 Oct 2000 18:29:26 -0500" Original-Lines: 88 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:32904 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32904 Rob Browning writes: > So I'm not an expert on maildir, but as I recall it keeps articles in > three subdirectories of the main directory right, Yes: tmp/, new/, and cur/. Messages are delivered by writing them to new files in tmp/. Once they're completely written, they get linked into new/, and are then considered delivered. MUAs look for new messages in new/ and rename them into cur/. nnmaildir does the renaming in -request-scan, and doesn't mark an article as read or not depending on whether it's in new/ or cur/. It could get by just as easily without moving articles at all. > I'm not sure I know exactly what's in the NOV lines, Article number, Subject:, From:, Date:, Message-ID:, References:, number of characters in message, number of lines in body. > as long as you have some "safety-net" code in there, this might even > be safe in the context of multiple gnus accessing the same group. Not at present, but I think that will be true to some degree in the future, as an accidental result of changes I'm planning. The information about the messages is checked at startup - the existence of the file is verified - but after that, if a message gets deleted from outside Gnus, and then you try to read it, you get an error, and nnmaildir doesn't condition-case it. > > Files are never rewritten, unless you edit an article, so the file's > > last-modified time gives you the delivery time. > > Is this an efficiency issue? It seems a little risky. It's a matter of treating message files as sacred. Delivery times could also be stored somewhere else, but they're never used in Gnus. > is delivery time not something that's normally in the article file? It isn't, although the mbox format adds it in the From_ line. > This sounds pretty good, but would it be helpful to make > groupdir/.nnmaildir a directory rather than a file? I don't think so. .nnmaildir contains two pieces of information about the group (name and largest article number), and then it's one line per message, containing the filename and NOV data. Fairly homogeneous. > > No splitting. (This is probably the big reason that nnmaildir > > doesn't inherit from nnmail.) Each maildir is a group. > > So how/when does the user see new groups? Do they have to manually > add each one? At present, yes. An nnmaildir select method looks like: '(nnmaildir "server name" (nnmaildir-groups ("/path/to/maildir" "/path/to/another"))) and each maildir is a group. But I think I'll change it to something like this: '(nnmaildir "server name" (nnmaildir-directory ("/path/to/dir"))) where /path/to/dir contains maildirs, or symlinks to them. New groups could be detected in -request-scan, and -request-create-group would become possible. > Looking at the spec, this sounds good, though it might be nice to have > two files in the long run, The "2," info is stored in the filenames themselves. I plan to store the 4 maildir marks there, and also all marks in .nnmaildir. .nnmaildir will be updated when the server is opened to reflect changes in marks made by a different mail reader, and files will be renamed to reflect changes in marks made by Gnus, so those changes will be visible to other mail readers. > In any case, it sounds like when you do this, the data in .newsrc.eld > will be irrelevant for your backend. Will gnus automatically prefer > the data in the backend to the .newsrc.eld file? The backend can provide a -request-set-info function, which will be called to correct Gnus's notion of marks and such. > It would also be nice if things were set up so that for similar > backends, there was a smaller set of functions that had to be > written to create each one. Moreso than nnoo allows, you mean? paul