From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/59088 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: IMAP article move Date: Tue, 09 Nov 2004 23:06:22 +0100 Message-ID: References: <4nr7n4b12g.fsf@lifelogs.com> <4nu0ryd6oj.fsf@lifelogs.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1100038295 7616 80.91.229.6 (9 Nov 2004 22:11:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 Nov 2004 22:11:35 +0000 (UTC) Original-X-From: ding-owner+M7628@lists.math.uh.edu Tue Nov 09 23:11:30 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CReD4-0003NV-00 for ; Tue, 09 Nov 2004 23:11:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1CReCh-0003hT-00; Tue, 09 Nov 2004 16:11:07 -0600 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1CReCd-0003hO-00 for ding@lists.math.uh.edu; Tue, 09 Nov 2004 16:11:03 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1CReCZ-0005Bp-VB for ding@lists.math.uh.edu; Tue, 09 Nov 2004 16:11:00 -0600 Original-Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by justine.libertine.org (Postfix) with ESMTP id 048813A004A for ; Tue, 9 Nov 2004 16:10:58 -0600 (CST) Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CReCW-0004IJ-00 for ; Tue, 09 Nov 2004 23:10:56 +0100 Original-Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Nov 2004 23:10:56 +0100 Original-Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Nov 2004 23:10:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: ding@gnus.org Original-Lines: 36 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:zTFCITnymz0ByHhWW0G5wR7lbO8= Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: main.gmane.org gmane.emacs.gnus.general:59088 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:59088 "Ted Zlatanov" writes: > On Mon, 08 Nov 2004, jas@extundo.com wrote: > >> What are you proposing? There is some optimization in >> nnimap-request-move-article and nnimap-request-accept-article to make >> moving more efficient, and I thought it was pretty fast. But I rarely >> copy/move articles, so I wouldn't know. Maybe you could illustrate by >> comparing which IMAP commands are sent now, and which commands you >> want to be sent? > > I apologize. Reading the source code, I thought that the IMAP COPY > (imap-message-copy) was not used, but it is. There does seem to be an > unnecessary full-body FETCH before the COPY, though, which is what > slows things down (I think). I just entered the group and did a `B m' > command, and the log showed that the article was fetched in its full > glory before it was moved. > > I think this is something that Gnus does for every backend when > moving, because it's needed in some cases (where you don't do the > internal backend move but a fetch+store instead). So the extra fetch > just needs to be eliminated when moving within the same IMAP server. > > nnml and nnmaildir could probably benefit from the same optimization, > if they do a file move internally as well. I agree. The problem is that nnimap-request-move-article doesn't know what the article will be used for, so it doesn't know whether to optimize away the FETCH or not. One kludge is to make B m bind a variable, say gnus-move-destination-group, that nnimap-request-move-article could look at, and if set it could simply refuse to return the article data, but perform the article move directly, to the g-m-d-g group. Hopefully there are cleaner solutions as well...