Re: slow nnimap moves due do many SELECTs

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Moving N articles results in:
>
> 09:00:37 190 SELECT "INBOX"
> 09:00:37 191 UID FETCH 274385 BODY.PEEK[]
> 09:00:37 192 UID COPY 274385 "INBOX.ding"
> 09:00:37 193 UID STORE 274385 +FLAGS.SILENT (\Deleted)
> 09:00:37 194 UID EXPUNGE 274385
> 09:00:37 195 SELECT "INBOX.ding"
> 09:00:37 196 UID SEARCH HEADER Message-Id "<87tylhhpie.fsf@lifelogs.com>"

[...]

> etc. for each article.  Can than be optimized to switch mailboxes only
> once?

Hm.  Well, the thing is that we need to select the group we moved to to
find out what the article number we got was.  Because Gnus needs that to
copy over the marks and other stuff.  So copying an article from group A
to group B involves at least to SELECTs.

However, it's possible to imagine an interface where you say "here's a
list of articles to move, and where they are going to be moved, and then
you return the list of article numbers".  Then nnimap could issue one
SELECT for the group you're moving from, and one SELECT per mailbox it
moved things to.  So if you moved 400 messages to INBOX.ding, there'd be
only two SELECTs.

However, this would require quite a bit of fiddling with the interface
functions...

But there may be other ways to fix this that I'm not seeing?  Is there a
way to get the UID of a message without SELECTing the mailbox it's in
first?  Or a way to get the new UID from the UID COPY command?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen