From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/47015 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: Do nnmail-split-fancy-with-parent for nnimap? Date: Sun, 06 Oct 2002 10:34:49 +0200 Organization: University of Dortmund, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <87wuowrmmu.fsf@crybaby.cs.uni-dortmund.de> References: <87y99cik4g.fsf@crybaby.cs.uni-dortmund.de> <87lm5cij8u.fsf@crybaby.cs.uni-dortmund.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1033893310 16747 127.0.0.1 (6 Oct 2002 08:35:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 6 Oct 2002 08:35:10 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17y6sW-0004Lp-00 for ; Sun, 06 Oct 2002 10:35:08 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17y6sY-0007Y8-00; Sun, 06 Oct 2002 03:35:10 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 06 Oct 2002 03:35:51 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id DAA09844 for ; Sun, 6 Oct 2002 03:35:38 -0500 (CDT) Original-Received: (qmail 25570 invoked by alias); 6 Oct 2002 08:34:51 -0000 Original-Received: (qmail 25560 invoked from network); 6 Oct 2002 08:34:50 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by gnus.org with SMTP; 6 Oct 2002 08:34:50 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 17y7eG-0006rd-00 for ; Sun, 06 Oct 2002 11:24:28 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 97 Original-NNTP-Posting-Host: p50877f9b.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1033896268 25176 80.135.127.155 (6 Oct 2002 09:24:28 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 6 Oct 2002 09:24:28 GMT User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) Cancel-Lock: sha1:zpDaldzGeQGoxaQPGkkk36kB8c8= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:47015 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:47015 Ted Zlatanov writes: > On Sun, 06 Oct 2002, Kai.Grossjohann@CS.Uni-Dortmund.DE wrote: >> >> The problem is backward compatibility. Suppose people have nntp as >> their primary server, and nnml and nnimap as secondary servers. >> Then right now foo.bar means the group nnml:foo.bar (because nnml is >> the "primary mail backend"), but your suggestion would change it to >> mean a group on the nntp server. > > Right, so the problem is that right now, the cache assumes nnml. You > could have a cache version at the top of the file (like BBDB), and > upgrade users to the newer cache version when they run the new > function, rewriting every group name to "nnml:groupname". That's a good idea, actually. > Or you could have a file called .nnimap.cache, separate from the nnml > cache. Right. >> (One possibility would be to make all groups be prefixed, maybe >> we could use "native" for the primary server.) > > That's what I was thinking, but realize that the "native" prefix or > whatever we use for the primary server is superfluous - if it's an > arbitrary string, you may as well skip it. No, with the suggestion "native:foo.bar" would be a new-style line whereas "foo.bar" would indicate an old-style line. Anyhow. All these methods are certainly viable methods. >>>> It would be really cool if ~/.nnmail-cache was stored on the >>>> server somehow. Is there a way to store data like this alongside >>>> IMAP mail on a server? >>> >>> I think the network usage would be too high for this. >> >> You must be kidding. Right now, nnimap splitting transfers each >> message over the net twice (one fetch from nnimap:INBOX, one put to >> the target group). I don't see how it can hurt to add 60 or 80 >> bytes to this traffic. > >> (It conceivable that .nnmail-cache must always be transferred in >> full, maybe via ange-ftp. This is a bad solution indeed, and for >> this your counter argument would be right. I wasn't even >> considering such bad solutions before you mentioned the possibility >> :-) > > You would have to either break up the cache in some way, or transfer > the entire cache every time. Yeah, I was thinking of just transferring new entries. The current implementation only does three operations on the cache: (1) append an item (at the end), (2) delete items from the front, and (3) search items in it. So just posting a message in a special group with the data in the subject or something like that would do the trick. But it would be quite inefficient. > You can store the cache in a group (e.g. "gnus-imap-split-cache") > that would basically be a mail group like any other; corruption of > its data is the user's problem. That's a good idea. > Any other storage of the cache would need support on the IMAP > server, AFAIK. Yes. I was hoping for some additional kind of protocols that IMAP servers are likely to speak. (Just as they now speak Sieve for another purpose.) > Now, if you transfer the entire cache, the chance of data corruption > is smaller, and the code is much simpler. That's the solution I > thought of, initially. Simplicity of implementation is a good thing, of course. > Breaking up the cache in some way would complicate the code > considerably. Also, you would have to devise an efficient way to > search all the cache elements for an article ID, or have the subject > of each article in the cache group somehow contain the article ID. > > Either way, with a single cache, or with a piecemeal cache, it's a lot > of traffic when your cache grows to 50000 articles. > > Am I missing something obvious? I don't think so. Thanks for your hints. kai -- ~/.signature is: umop ap!sdn (Frank Nobis)