From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32903 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.gnus.general Subject: Re: "Fixing up" gnus - (how hard is this?). (was Re: (provide 'nnmaildir)) Date: 19 Oct 2000 18:29:26 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <87bswg1kbt.fsf@raven.localnet> References: <87aec3o3u6.fsf_-_@raven.localnet> <871yxfnlnz.fsf@raven.localnet> <87g0lt9amk.fsf@raven.localnet> <87hf697kba.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 1035169108 22382 80.91.224.250 (21 Oct 2002 02:58:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:58:28 +0000 (UTC) Cc: ding@gnus.org 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 20B86D0645 for ; Thu, 19 Oct 2000 19:30:27 -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 SAB13319; Thu, 19 Oct 2000 18:30:00 -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 18:29:21 -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 SAA17693 for ; Thu, 19 Oct 2000 18:29:06 -0500 (CDT) Original-Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54]) by mailhost.sclp.com (Postfix) with ESMTP id BFCB3D0645 for ; Thu, 19 Oct 2000 19:29:32 -0400 (EDT) Original-Received: from omen.localnet ([24.162.113.38]) by mail.austin.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 19 Oct 2000 18:31:31 -0500 Original-Received: from raven.localnet (raven.localnet [192.168.1.7]) by omen.localnet (Postfix) with ESMTP id 0BD0827C4B; Thu, 19 Oct 2000 18:29:32 -0500 (CDT) Original-Received: by raven.localnet (Postfix, from userid 1000) id A2647AEA4; Thu, 19 Oct 2000 18:29:26 -0500 (CDT) Original-To: prj@po.cwru.edu (Paul Jarc) In-Reply-To: prj@po.cwru.edu's message of "19 Oct 2000 12:05:00 -0400" Original-Lines: 92 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:32903 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32903 prj@po.cwru.edu (Paul Jarc) writes: > I haven't measured, but I'd expect nnmaildir to compare well > speedwise. Each message is in a separate file, and it generates a > NOV line when a new message is first seen, so it should be > comparable to nnml. So I'm not an expert on maildir, but as I recall it keeps articles in three subdirectories of the main directory right, and one of those subdirs is where all the new articles go, so for this backend, figuring articles will be in different locations depending on their state, or do you just treat the new article subdir as the spool dir and immediately move the articles elsewhere when gnus checks for mail? > While the server is open, a structure is kept in memory, that holds > the NOV lines associated with each article; they're read from disk > only at startup. I'm not sure I know exactly what's in the NOV lines, but presuming it's just article info, 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. You'd just detect the changes the next time you tried to access something that had changed... > 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. If I tar up my directory, and forget to use "p", or if the system clock is screwy, I get the wrong answer, or is delivery time not something that's normally in the article file? An alternate approach would be to just use caching of some flavor. Store the date in a file in groupdir/.nnmaildir (or whatever). > (Modulo an unsolved bug in -request-{move,accept}-article.) The > file that stores group information, including NOV lines, is written > frequently and reliably - the file ".nnmaildir" always exists (after > it's been written once) and it's always consistent. This sounds pretty good, but would it be helpful to make groupdir/.nnmaildir a directory rather than a file? We did that for gnucash's user startup/config files, and it made keeping track of things somewhat cleaner - separating state data from config data in separate files, making parsing easier because the contents of each data file can be more limited, etc. FWIW. > 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? It might sound crazy, but I had always kinda wanted a backend that was more like dired. I'd just see what's in the (sub)tree and could manipulate things however I like, either from gnus, or from the shell. In that situation, you could either have a manual update button to tell gnus to detect any changes (deleted/moved groups), etc., or have gnus do the equivalent of a diff on "find my-mail-tree -type d" every now and then to see if it needs to rescan. > The next version will store marks, in such a way that you should be > able to use other maildir readers on the same maildir between Gnus > sessions, and the two will see (some of) each others' marks. > (Assuming the other reader uses the "2," info format described in > the link above - I don't know if there are any such readers.) Looking at the spec, this sounds good, though it might be nice to have two files in the long run, one that stores the "2," format as it evolves and another that's a superset of that so if you want to store more info, info that other mailers can't necessarily understand, you have somewhere to keep it out of harms way (in other words, the "2," file would be derived from the data in the superset file which would probably be elisp/scheme forms). Though I suppose you can worry about that once you find something you want to put in the superset... 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? > I'd especially like to see documentation of what triggers each backend > function, and what assumptions, if any, they can make about their > environment - current buffer, etc. Yep. It would be nice to have a well-documented interface (even if we had to write a little bit of "adapter" code) that all of the backends could be modified to conform to. 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. There might be a set of default functions for things like article-state->form form->article-state, etc. You wouldn't have to use these, but you could if/when you didn't need anything more tailored. -- Rob Browning PGP=E80E0D04F521A094 532B97F5D64E3930