Re: Agent expiration

["Kevin Greiner" <kevin.greiner@compsol.cc>]

From: Gregory Novak <novak@ucolick.org>

>>> [I]s there a command to remove messages from the agent that 
have
>>> disappeared from the imap server?  gnus-agent-expire doesn't 
(seem)
>>> to do what I want, given that it will get rid of all messages 
older
>>> than some age.
>>
>> gnus-agent-regenerate-group may help (but may be harmful too, I 
don't
>> really know).
>
>I've seen similarly cryptic and vaguely frightening comments about
>gnus-agent-regenerate-group on archives of this list I've been 
reading
>over the past week or so.  Could someone elaborate about what's 
going
>on with this command?

I'm not at all certain how the "vaguely frightening" comments came 
to be except that, like all rumors on the net, they do seem to 
have a life of their own.  They may have actually resulted from my 
discouraging people from running gnus-agent-regenerate-group every 
time they entered, or exited, a group.  It's a CPU/time expensive 
function to call and, if things are working as intended, 
completely unnecessary.

The original need for regenerate group came about to help users 
whose connections were dropped while downloading content.  The 
architecture of the agent is such that article content is first 
fetched and parsed into individual files. Later, the group status 
is updated to indicate that those articles have been downloaded.  
As a result, if you lost your connection in the middle of a 
download, you would have downloaded articles on your hard drive 
that where not known to gnus.  If you tried downloading again, you 
would end up downloading the same articles that are already on 
your hard drive.  If you instead used gnus-agent-regenerate-group, 
gnus would be updated to know about all of the downloaded articles.

After building that, I realized that gnus-agent-regenerate-group 
offered all sorts of interesting possibilities.  As a result, I 
added the option to mark downloaded articles as unread.  With the 
current capabilities you can, for example, move downloaded 
articles between servers and/or groups.

As for sync'ing the agent with your imap server, that is a bit of 
a problem.  The issue is that the agent is middleware that has no 
knowledge of the backend server.  I'll use an example to explain.  
Let's say that you have 10 messages in your imap folder and that 
you've used gnus to view the list of messages.  At this point, 
gnus knows that you have 10 unread messages.  The next time you 
open this folder, gnus will send a command asking for the headers 
of 10 articles.  If the agent is turned off, this request is sent 
to nnimap which might only return 7 headers(3 having been expired, 
moved, etc outside of gnus control).  On the other hand, if the 
agent is turned on, the agent will intercept the original header 
request and return the 10 headers from your hard drive.  The 
result is you see articles that no longer exist on your server.  
If you had deleted those articles using gnus, then gnus would know 
that only 7 articles existed so it would never have requested the 
3 deleted articles from the agent.

I haven't tried this as I don't use nnimap except for testing the 
agent but it is easy and safe.  Try turning the agent off for your 
nnimap server then open the out-of-sync folder.  Gnus may, as a 
side-effect of parsing your server's response, update its own 
state to remember the changes that have occurred in your imap 
server.  If that is actually true, you will be able to turn the 
agent back on and not see the out-of-date articles.

Kevin 

________________________________________________________________
Sent via the EV1 webmail system at mail.ev1.net