Re: nnimap: article moving

[Simon Josefsson <sj@extundo.com>]

NAGY Andras <nagya@inf.elte.hu> writes:

> Been curious how efficiently nnimap works

Nnimap is painfully slow.

At some point (or rather an interval) in time, I hope to extend the
Gnus<->backend interface to make IMAP groups work much faster.  Don't
blame IMAP for nnimap speed, IMAP can be very fast.

Two hints to speed things up considerably (at least if your reading
habits are close enough to mine):

(setq gnus-keep-backlog 10
      gnus-asynchronous t)

> and made the following test: select an nnimap group, do not view any
> articles, but select one in the summary buffer.  Press B m
> (gnus-summary-move-article), enter a mailbox name on the same
> (physical and virtual) server, press ENTER and leave the group.
> 
> I'd expect nnimap to do a server-side move (copy uid and mark as
> deleted), without downloading the article.  Unfortunately, the article
> is downloaded _two times_, but interestingly, not uploaded again, so
> the server-side move actually takes place, but why the download then?

Nnimap does not know that the target is a nnimap group at the time the
article is fetched.  So it download the article and save some
variables, and if nnimap is later invoked with an instruction to
"accept" a new article, it notices the variables and simply invoke a
"move" command rather than uploading the article.

As for downloading the article twice, that's simply stupid.  imap.el
actually cache stuff so nnimap should take advantage of that.
However, perhaps `gnus-keep-backlog' work too?

Perhaps the Gnus Move command can "hint" to the backend what the
target group is.  Hm.