Re: Outstanding stuff?

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 24 Oct 2010 19:20:00 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

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

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

If Gnus (and Emacs) were multithreaded this would be a great place to
use it.  Do you think this can be done with async messages (IMAP allows
it, obviously, but Gnus would need to update things as replies arrive)?

Maybe the whole IMAP interaction should be designed as an async queue
(with the option to insert at either end) rather than a command-reply
serial stream.

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

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

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

The Gnus registry should be updated, but it doesn't need the article
number.  For a move from A to B, it only needs to be told the message ID
is no longer in group A and is now in group B.  Right now it does that
with a hook that you will bypass with this special function.

I am suspicious of such special functions.  If there's a way to make
moves faster, shouldn't all backends benefit from it?

Ted