From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/31789 Path: main.gmane.org!not-for-mail From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: (provide 'nnmaildir) Date: Sat, 15 Jul 2000 13:43:06 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035168159 16061 80.91.224.250 (21 Oct 2002 02:42:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:42:39 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35]) by mailhost.sclp.com (Postfix) with ESMTP id C5553D051E for ; Sat, 15 Jul 2000 07:45:51 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id GAC15347; Sat, 15 Jul 2000 06:45:35 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 15 Jul 2000 06:43:26 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id GAA09163 for ; Sat, 15 Jul 2000 06:43:11 -0500 (CDT) Original-Received: from waldorf.cs.uni-dortmund.de (waldorf.cs.uni-dortmund.de [129.217.4.42]) by mailhost.sclp.com (Postfix) with ESMTP id 5BD7DD051E for ; Sat, 15 Jul 2000 07:43:44 -0400 (EDT) Original-Received: from marcy.cs.uni-dortmund.de (marcy.cs.uni-dortmund.de [129.217.20.159]) by waldorf.cs.uni-dortmund.de with ESMTP id NAA19889; Sat, 15 Jul 2000 13:43:07 +0200 (MES) Original-Received: from lucy.cs.uni-dortmund.de (lucy [129.217.20.160]) by marcy.cs.uni-dortmund.de id NAA11124; Sat, 15 Jul 2000 13:43:07 +0200 (MET DST) Original-Received: (from grossjoh@localhost) by lucy.cs.uni-dortmund.de (8.9.3/8.9.3/Debian 8.9.3-21) id NAA08562; Sat, 15 Jul 2000 13:43:06 +0200 X-Authentication-Warning: lucy.cs.uni-dortmund.de: grossjoh set sender to Kai.Grossjohann@CS.Uni-Dortmund.DE using -f Original-To: Paul Jarc In-Reply-To: Paul Jarc's message of "14 Jul 2000 19:10:18 -0400" User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.0.90 Original-Lines: 131 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:31789 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:31789 On 14 Jul 2000, Paul Jarc wrote: > - Message files will never be rewritten. The data in the files and > the last-modified times are to be treated as precious. I've > thought about encoding NOV lines in the filenames for easy access, > but that might get a bit unwieldy. (I do add Lines: when writing > the full headers to nntp-server-buffer, but I don't write it back > to the message file.) I could just write the NOV lines to a > separate per-maildir file, but that's so boring. It'd complicate > message deletion, too. I think doing the NOV thing is important to gain speed. The Gnus backend interface heavily relies on the data contained in NOV lines, and there are quite highly optimized functions for dealing with NOV lines. nnimap has code for retrieving header data from the IMAP server and then caching this data in NOV format on the local disk. Maybe that kind of approach would work for you, too? The first time you enter a group, you gather NOV lines for all messages, and on subsequent visits you just read that cache file. > - I've been using the message files' inode numbers as article > numbers. It seems this won't be viable, though, since messages > are sorted by article number in the summary buffer. Yes, article numbers must be monotonically increasing. I you use a NOV cache as described above, you could put the article numbers into that file. You could also store the maildir file name in the NOV cache, and then you could get a list of files in the directory and a list of file names from the NOV cache, and compare. This would help you find NOV lines for the new messages, and it would help you delete stale lines from the NOV cache. > So... what conditions are article numbers supposed to satisfy? What > do NNTP servers do when they run out (I'm assuming they don't use > bignums), and how does Gnus react? Gnus gets real mad when the article numbers are reset. This is a weak spot. Gnus has not been designed for this. You can use M-x gnus-group-clear-data RET and/or gnus-group-clear-data-on-native-groups to make Gnus forget all article numbers. This means that all messages will be considered new, unread. > The server argument to the backend functions is the second element > of the select method, right? I don't think so. It just identifies a server. There are two ways to identify a server. One way is to use a string, which is treated like a name and then looked up in the list of all servers. The other possibility is to have a complete server definition, along the lines of (nnml "frumple" (nnml-get-new-mail nil)), ie with server parameters and all. Luckily, it appears that you don't have to think about all this stuff -- you can just use nnoo-change-server and then access local variables, or stuff like this. Hm. Hmmm... I have written a backend which seems to work, and I still don't know what that server argument really means. It appears that nnoo is your friend, because it means you don't have to know all the gory details. > A string, typically? And as the author of the backend, I decide > what it means? (Right now, I'm using it to specify the path to the > maildir, but I think I'll create a backend variable for that purpose > instead.) Well, you could assign to it some meaning. But I think it would be better to just treat it as a name. This way, users can decide what their group names look like. You see, if you specify (nnmaildir "frumple" ...) as a server definition, then you will have group names like nnmaildir+frumple:foo.bar. If you specity (nnmaildir "" ...), ie an empty server name, then the groups are named nnmaildir:foo.bar. By `name' I mean that what you enter after a `B m' prompt, for example. > I'm unclear about the usage of nnoo-change-server and > nnoo-push-server. I've just been working from (un/sparsely > commented) examples in the various nn*.el to guess where to use > each. I wish I knew... > Can I see a concrete example of what a real-life NOV line would look > like, as written to nntp-server-buffer? Lessee: 1 Username/password for submission of ECDL paper Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) 28 Apr 2000 16:17:50 +0200 160 7 Xref: lucy.cs.uni-dortmund.de conf.y2000.ecdl:1 To: ecdl2000@bn.pt These are tab-separated fields. The first field is the article number, the second field is the Subject header, then comes the From header, then the date, then the message id, and I'm not sure about the two numbers 160 and 7. Then comes the Xref header (I'm not sure what that means), and the remaining fields can be any headers from the message. (See gnus-extra-headers and nnmail-extra-headers for the remaining fields.) But this format is surely described somewhere in the Gnus info file? > Can I get away with using article numbers for references there? Gnus identifies messages by their numbers. > Why does gnus-nov-is-evil exist? Obeying it might be mildly > troublesome/expensive. Yes. But if the user wishes to do that... > Does the `chars' field include the whole message, or just the body? > `lines' is just the body, right? Err... > How does Gnus know whether a backend supports article identification > by article number ranges or Message-IDs? I guess backends must fail > sensibly if they don't support these, hm? I think Gnus will barf if the backend doesn't support article numbers. Maybe it's sufficient to just signal an error for message ids. kai -- I like BOTH kinds of music.