Re: Outstanding stuff?

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

Robert Pluim <rpluim@gmail.com> writes:

> Actually, now that I've read the relevant section of the IMAP rfc for
> the first time in my life, I'm more suspicious about the BODY.PEEK[]
> thing, doesn't that download the entire message? Surely at most the
> headers are required?

Yes, and I've now made that change, so I now get this pattern:

19:05:12 1086 SELECT "efn"
19:05:12 1087 UID FETCH 42 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
19:05:12 1088 UID COPY 42 "Test"
19:05:12 1089 UID STORE 42 +FLAGS.SILENT (\Deleted)
19:05:12 1090 EXPUNGE
19:05:12 1091 EXAMINE "Test"
19:05:12 1092 UID SEARCH HEADER Message-Id "<alpine.LRH.2.00.1009181734090.29309@luke.ifi.uio.no>"
19:05:12 1093 SELECT "Test"
19:05:12 1094 UID STORE 4 +FLAGS.SILENT (\Seen)
19:05:12 1095 SELECT "Test"
19:05:12 1096 UID FETCH 1:* FLAGS

Which is still way excessive, but let's examine it and consider what our
options are for speeding this up.

19:05:12 1086 SELECT "efn"

Can't be removed, but could (in theory) happen once.

19:05:12 1087 UID FETCH 42 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
19:05:12 1091 EXAMINE "Test"
19:05:12 1092 UID SEARCH HEADER Message-Id "<alpine.LRH.2.00.1009181734090.29309@luke.ifi.uio.no>"

We need the Message-ID of the message if we're going to return the
article number.  The question is: Do we need the article number, and the
answer is "kinda".  If the method is covered by the Agent, or the
message is cached, or whatever, then we need to know the new article
number so that we can do the right things there.  We also update the
marks in Gnus immediately, so we need the article number for that too,
although we could do without, since the next `g' will update Gnus
wrt. the target group anyway.  (If that group allows flags.)

So: If we want a sloppier not-quite-coherent update, we could get rid of
those.

19:05:12 1088 UID COPY 42 "Test"

Can't be removed.  :-)

19:05:12 1089 UID STORE 42 +FLAGS.SILENT (\Deleted)

Could be batched.

19:05:12 1090 EXPUNGE

Could easily be postponed until the last move.

19:05:12 1093 SELECT "Test"
19:05:12 1094 UID STORE 4 +FLAGS.SILENT (\Seen)

This is probably superfluous?  IMAP probably copies over all the marks
anyway? 

19:05:12 1095 SELECT "Test"
19:05:12 1096 UID FETCH 1:* FLAGS

I have no idea what's this is about.

Oh, it's this thing at the end:

    ;; Re-activate all groups that have been moved to.
    (with-current-buffer gnus-group-buffer
      (let ((gnus-group-marked to-groups))
	(gnus-group-get-new-news-this-group nil t)))

But that's only done once per move.        

So I'm not sure how much faster things could be without making things
kinda weird.

HOWEVER, we could just cheat and totally special-case things for
nnimap.  That is, a new interface function

(*-request-move-articles-internally articles from-group server to-group)

If it exists, and the move is internal (from one group on the same IMAP
server to another), this would just issue COPY + \Deleted + EXPUNGE, and
forget about all Gnus niceties with the cache/agent/etc.

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