manage agentized groups

manage agentized groups

[Harry Putnam]

>From earlier post:

"I want to go thru those agentized groups and split out the messages by
mnth to nnml groups of similar names.  That part is not a problem.  I
know how to do that."

Above turns out to be a bit of an exaggeration.  The splitting into
maillike files and then respooling is easy enough, but what to do with
the now empty or nearly empty News/agent/..../comp/groups?

I still want to use these agentized groups to continue screening and
downloading messages, but what about the
News/agent/nntp/SERVER/agent.lib/history and the group ".agentview"
and ".overview" files?

Can these just be ignored... The idea of hand editing them is
definitely not appealing.  If I delete them and start over there will
be about a month overlap in what has been already sent to nnmml
grouos.  There should be a clean way to do this.

What will happen in this situation?

Empty agent group
.overview, .agentview history files still reflect the situation before
moving thousands of messages to their new nnml home.

We really do need some built-in ways to handle agentized messages.  It
seems agent development has stopped when about 1/2 way through.

I'd love to do work on that but the fact is I am just not skilled or
knowledgeable enough to do so.  Still it seems, for gnus  to call itself an
"offline" reader, some work is required.

Agent expiry could possibly be finished giving, a smooth way to handle
the above situation.

Re: manage agentized groups

[Kai Großjohann]

Harry Putnam <reader@newsguy.com> writes:

> Agent expiry could possibly be finished giving, a smooth way to handle
> the above situation.

Well, maybe gnus-agent-expiry could be changed so that it calls a
user-customizable function on each message to be expired rather than
just deleting it?

kai
-- 
Life is hard and then you die.

Re: manage agentized groups

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > Agent expiry could possibly be finished giving, a smooth way to handle
> > the above situation.

> Well, maybe gnus-agent-expiry could be changed so that it calls a
> user-customizable function on each message to be expired rather than
> just deleting it?


I kind of like the notion of applying the full range of Mail commands
to agentized groups.  Move copy delete expire edit split etc etc.
After all these files are wholly owned by "agent".  What is
the big stumbling block there anyway? :)

Is there already a way to do this?  Move the accumulated agentized
messages to nnml groups of similar names,up to a certain date.  Run
agent expiry up to that same date with out overlapping.  Or with some
measure of accuracy.

Compared to the sophisticated expiry  scoring/expiry etc, that is
possible on mail groups ... Agent expiry is a primitive clunker.