From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5551 Path: main.gmane.org!not-for-mail From: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) Newsgroups: gmane.emacs.gnus.general Subject: Re: performance respooling articles in nnmbox or nnbabyl Date: 16 Mar 1996 10:58:04 +0100 Organization: Dept. of Informatics, University of Oslo, Norway Sender: larsi@ifi.uio.no Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146139 680 80.91.224.250 (20 Oct 2002 20:35:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:35:39 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.3/8.6.9) with SMTP id CAA08936 for ; Sat, 16 Mar 1996 02:52:47 -0800 Original-Received: from eistla.ifi.uio.no (4867@eistla.ifi.uio.no [129.240.94.29]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 16 Mar 1996 10:58:06 +0100 Original-Received: (from larsi@localhost) by eistla.ifi.uio.no ; Sat, 16 Mar 1996 10:58:05 +0100 Original-To: ding@ifi.uio.no In-Reply-To: gsstark@MIT.EDU's message of 15 Mar 1996 20:30:53 -0500 Original-Lines: 42 Xref: main.gmane.org gmane.emacs.gnus.general:5551 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5551 gsstark@MIT.EDU (Greg Stark) writes: > The problem is that nnmbox and nnbabyl use a single file for all the > groups and use the Gnus-* headers to indicate which group an article > is in. To refile an article, all that's necessary is to change the > header, in theory. Some header munging also has to be done to remove all those babyleze headers. > If it just went through and editted the headers for each article it > would only have to move the gap over each article once in sequence, > the equivalent of a single movement over the entire buffer. In > other words it should run in order N time. If there's no clean way > to get this behaviour without breaking the abstraction barriers (it > looks like it shouldn't be too hard to me) then another order N > algorithm would be to process all the deletions first then insert > all of them at the end. But you're only considering the particular case of respooling between nnbabyl and nnmbox (and possibly nnfolder). You're probably right that Gnus does far too much work when moving messages between those backends, but it's hard to see how to do what you suggest between, say, nntp and nnml cleanly without adding a gazillion new functions. (Each backend now only has to provide two functions to move, accept, copy and respool articles -- `nn*-request-move-article' and `nn*-request-accept-article'.) The added complexity does not justify the speed increases, which I'm not convinced would happen, actually. (I don't know anything about those buffer gaps and stuff, though. Why do the gaps have to move? Point stays at the end of the buffer being respooled to, I think...) Oh. Uhm. I misunderstood. You meant respooling using the same backend? Those backends assume that the messages are stored using ascending article numbers, so just changing the Gnus-* headers won't work reliably. In any case, that's not something most people would do very often. -- "Yes. The journey through the human heart would have to wait until some other time."