Move messages while offline using registry?

Move messages while offline using registry?

[Kai Großjohann]

Now that the registry is there, it could be used to implement moving
messages while offline.  First of all, you'd need a place to stash
the to-be-moved messages.  Maybe nndraft:moving, or something.
Secondly, you'd need a data structure giving, for each group, a list
of msgids of messages that are to be moved into that group.  And the
last piece in the puzzle is something that injects additional
articles into a group, along the lines of `G j', perhaps.

What do people think?

Hm.  It would also have some facily of marking the messages that are
still in nndraft:moving.  

Hm.  I wonder if it could be easier to implement a backend that stores
messages by their message id and that maintains a mapping between
numbers and ids.  Then the agent could be changed to use that backend.
Then articles could be moved while offline.  No, it doesn't really
sound easier.  Maybe it is better to stick with the old article
number approach.
-- 
A turnip curses Elvis

Re: Move messages while offline using registry?

[Ted Zlatanov]

On Fri, 07 Feb 2003, kai.grossjohann@uni-duisburg.de wrote:
> Now that the registry is there, it could be used to implement moving
> messages while offline.  

As of today, I think it's ready.  More or less.

> First of all, you'd need a place to stash the to-be-moved messages.
> Maybe nndraft:moving, or something.  Secondly, you'd need a data
> structure giving, for each group, a list of msgids of messages that
> are to be moved into that group.  And the last piece in the puzzle
> is something that injects additional articles into a group, along
> the lines of `G j', perhaps.

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.

> Hm.  I wonder if it could be easier to implement a backend that
> stores messages by their message id and that maintains a mapping
> between numbers and ids.  Then the agent could be changed to use
> that backend.  Then articles could be moved while offline.  No, it
> doesn't really sound easier.  Maybe it is better to stick with the
> old article number approach.

I honestly do not know.  I would guess it's a lot of work in the
backend, though.  Maybe the registry could be used to trace a message
ID to the group and article ID it currently occupies.  That's not too
hard, though the registry hooks will have to be modified to also take
the new article ID.

Ted

Re: Move messages while offline using registry?

[Ted Zlatanov]

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

Re: Move messages while offline using registry?

[Frank Schmitt]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Hm.  I wonder if it could be easier to implement a backend that stores
> messages by their message id and that maintains a mapping between
> numbers and ids.  Then the agent could be changed to use that backend.
> Then articles could be moved while offline.  No, it doesn't really
> sound easier.  Maybe it is better to stick with the old article
> number approach.

Would this mean, I can read news at different places from different
servers and Gnus still knows which have been read, answered etc as long
as I copy newsrc.eld and newsrc?

If yes, this would be extremely cool.

-- 
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.

Re: Move messages while offline using registry?

[Simon Josefsson]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Hm.  I wonder if it could be easier to implement a backend that stores
>> messages by their message id and that maintains a mapping between
>> numbers and ids.  Then the agent could be changed to use that backend.
>> Then articles could be moved while offline.  No, it doesn't really
>> sound easier.  Maybe it is better to stick with the old article
>> number approach.
>
> Would this mean, I can read news at different places from different
> servers and Gnus still knows which have been read, answered etc as long
> as I copy newsrc.eld and newsrc?
>
> If yes, this would be extremely cool.

This should already work for nnimap, and for nnml if you copy the
.marks file and for nnfolder if you copy the .mrk file.  It was
possible before too if you copied the .newsrc.eld, but that file
contains other stuff as well so it wasn't as flexible.  Assuming I
didn't misunderstand something here.

Re: Move messages while offline using registry?

[Frank Schmitt]

Simon Josefsson <jas@extundo.com> writes:

> Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:
>
>> Would this mean, I can read news at different places from different
>> servers and Gnus still knows which have been read, answered etc as long
>> as I copy newsrc.eld and newsrc?
>>
>> If yes, this would be extremely cool.
>
> This should already work for nnimap, and for nnml if you copy the
> .marks file and for nnfolder if you copy the .mrk file.  It was
> possible before too if you copied the .newsrc.eld, but that file
> contains other stuff as well so it wasn't as flexible.  Assuming I
> didn't misunderstand something here.

I was talking about Usenet news.

-- 
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.

Re: Move messages while offline using registry?

[Kai Großjohann]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Hm.  I wonder if it could be easier to implement a backend that stores
>> messages by their message id and that maintains a mapping between
>> numbers and ids.  Then the agent could be changed to use that backend.
>> Then articles could be moved while offline.  No, it doesn't really
>> sound easier.  Maybe it is better to stick with the old article
>> number approach.
>
> Would this mean, I can read news at different places from different
> servers and Gnus still knows which have been read, answered etc as long
> as I copy newsrc.eld and newsrc?

I was talking about a backend that stores mail.  Unlike nnml, it
wouldn't use article numbers for file names.

Changing nntp would be something different.  Hm.

> If yes, this would be extremely cool.

Hm.  Yeah, in a way it would.

I'm afraid of opening a can of worms, though.
-- 
A turnip curses Elvis