Re: Make gnus-agent another mail backend?

[Harry Putnam <reader@newsguy.com>]

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

> Harry Putnam <reader@newsguy.com> writes:
>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Harry Putnam <reader@newsguy.com> writes:
>>>
>>>> What is the difference?  Would one have to do some kind of work to get
>>>> them into a state (in cache?), where this editing or other maillike
>>>> things could happen? 
>>>
>>> You would press `e', and the rest would happen automatically.
>>
>> When I press `e' on an agentized message nothing like that happens.
>> I'm told it isn't allowed.
>
> Lars meant that he wants to implement a feature so that you can just
> hit `e', and then Gnus would put the message in the cache for you,
> and then allow you to edit that cached message.

That would be nice.

> Lars is further asking whether this feature would make you happy.
> And if it doesn't, why not.

If Lars' `press e' plan could be automated by scoring or something
then it would be very much like the `scimming' plan laid out below.
Except the cache doesn't act like a mail backend. (Does it?)

As reported earlier, the real intent of all my blabbing is to allow
the creation of a filtered (i.e. concentrated) database of agentized
messages.  Some way to automate first screening (filtering) then
storing, in reasonable sized (probably less than 3,000 files)
consecutive named, or some similar dated scheme containing the group
name and month or the like.  This might involve adding certain info to
the headers or the like and thereby the editing necessity.

Things that would do that are now mostly possible in mailgroups but
not nntp or agentized_nntp groups.  In fact some of it isn't really
possible anywhere I don't think.  The idea of initiating some
archiving or targetted_expiry or the like on the basis of score, age
and readedness really doesn't seem currently possible, without some
smart hacking.

So to get to the answer... It isn't clear how pressing `e' to move a
message to cache will facilitate any of this.  Near as I can tell
cache doesn't allow the other mailbackend things like complex
expiry that would make it fly.  If editing were the only desired
result then that would satisfy it.

I'm now thinking that scimming off (by duplication) incoming agent
messages would be a better approach.  It wouldn't require any changes
to the agent by and large.   Maybe not particulary econmical but that
isn't really a requirement here.  However it would require some kind
of intervention right at the download level.  Maybe something like
allowing a suffix to be applied to newsgroup being downloaded and a
duplicate of the messages sent to the nnmaildir:news.group.suffix.
(or nnml).  

Agent messages can be fleeting if one uses agent-expire regularly so
it wouldn't mean mass duplication for ever.

I'm thinking of scimming incoming agent messages into a mailbackend,
maybe nnmaildir would be easiest, but possibly nnml too.  Once there,
most of the rest is already part of mailbackend possibilities.

One major thing lacking is a built in way to cause action to be taken
on messages by a score file.  I mean beyond marking them read.
For example: A score file that promotes a message to a score above
default would then move it to an archive somehow.  If it were demoted
below default it would be deleted or earmarked for expiry.

Marking as read seems to be the only action allowed.  But more than
likely its my lack of lisp skills showing.  Causing a header to be
added on the basis of score.. 

   X-Gnus-Score: gnus_score=5 Wed Jan 23 07:57:32 PST 2002

.. might be usefull since it would allow other tools to learn of gnus
ideas of what is scored above default, without bothering gnus for the
info.  This would require the ability to edit and save the edited
version to current group.

What if one of the hand scoring rules was setup to write such a header
as its action part?  Then one could create temporary hand scores that
would leave permanent evidence but would not incur the major overhead of
scoring masses of files when the group is opened.