Re: Move messages while offline using registry?

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 07 Feb 2003, tzz@lifelogs.com wrote:
> Shouldn't be too hard.  Insert (in the global registry that's still
> to come) something like this associated with the message ID:
> 
> '('queued-move-when-connected group-name)
> 
> then on startup, Gnus can scan the registry and (if connected) do
> the move.

I was thinking more about this, and it seems to me like a Gnus action
handler would be a nice thing.

Consider the current situation: there are hundreds of functions, a
dozen per backend, that follow a naming convention - for instance,
nnimap-request-newgroups which corresponds to the 'request-newsgroups
action.  What if, instead of running those functions directly, user
requests put actions (for instance, 'request-newsgroups) on a queue,
and then Gnus could process those actions off the queue as they come
in?  Each backend would have its own action handler, and a central
routing function would send each action from the main queue to the
appropriate action handler in the respective backend.

This, of course, applies only to non-interactive actions, such as
"move article" or "set mark."

To create complex behavior for a message - for instance, "move to
group X and set mark to Y" simple actions can be queued as a group.

A big advantage is that the queue can be traced backwards, providing a
limited sort of undo.  Of course, a deleted message can't be
recovered, but an article move or erroneous spam processing of a ham
article could be retraced backwards.  That would be a good thing, I
think.

Another advantage is that offline work becomes simply a matter of
saving up the event queue until Gnus is online again.

Maybe asynchronous events can be implemented in this event queue, so a
user can read one article while another is being moved or copied.  I
don't know how well Emacs can handle this, but asynchronous events
could be limited to only a few "safe" combinations.

Things like the message registry, spam/ham processing, and any code
that needs to know the *past* of an article, not just its current
state, would be much simpler this way.

It seems to me that this is a significant amount of work, and maybe it
doesn't make sense to change Gnus in such a fundamental way (either
because the gains are not worth the effort, or because it's too much
work altogether).  What do you think?

Ted