Re: IMAP article move

[Simon Josefsson <jas@extundo.com>]

"Ted Zlatanov" <tzz@lifelogs.com> 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...