Make gnus-agent another mail backend?

Make gnus-agent another mail backend?

[Harry Putnam]

Is it reasonable to think of making the agent another mail backend?

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

Harry Putnam <reader@newsguy.com> writes:

> Is it reasonable to think of making the agent another mail backend?

I don't think so.  The Agent is a middle-ware layer, while mail
back-ends (like news back-ends) are, well, back-ends.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Paul Jarc]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Harry Putnam <reader@newsguy.com> writes:
>> Is it reasonable to think of making the agent another mail backend?
>
> I don't think so.  The Agent is a middle-ware layer, while mail
> back-ends (like news back-ends) are, well, back-ends.  :-)

Could the Agent be changed to use a normal mail backend for its
storage?  So agentization would be a kind of connection between two
groups rather than an attribute of oen group?  I think that would give
Harry what he wants.


paul

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Could the Agent be changed to use a normal mail backend for its
> storage?

It does -- nnagent is just a layer on top of nnml.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Paul Jarc]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> Could the Agent be changed to use a normal mail backend for its
>> storage?
>
> It does -- nnagent is just a layer on top of nnml.

Are the nnml groups exposed so they could be used like normal nnml
groups?  Would it do any harm to remove or edit articles in those
groups?  Could nnagent use a user-specified backend instead of always
nnml?


paul

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Are the nnml groups exposed so they could be used like normal nnml
> groups?

Almost...

> Would it do any harm to remove or edit articles in those groups?

Yes.  It would make the Agent's storage not correspond with the real
server storage, meaning that we would have to implement ways of not
letting expiry touch certain articles, etc.

> Could nnagent use a user-specified backend instead of always nnml?

Not without a lot of work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> prj@po.cwru.edu (Paul Jarc) writes:
>
>> Are the nnml groups exposed so they could be used like normal nnml
>> groups?
>
> Almost...
>
>> Would it do any harm to remove or edit articles in those groups?
>
> Yes.  It would make the Agent's storage not correspond with the real
> server storage, meaning that we would have to implement ways of not
> letting expiry touch certain articles, etc.

But isn't that already the case?  The stuff in an agentized group can
way outdate what is on the server.  Keeping up with that difference
was implemented way back about pgnus-[20-21].

>> Could nnagent use a user-specified backend instead of always nnml?
>
> Not without a lot of work.

What about just intervening in the actual download and forcibly
producing copies to something like $nnmaildir/some.group/new and
letting the dup go on to its agent destination to be dealt with by
agent-expiry.

Or maybe to a spool like $spool/some.group.in by adding the needed
mbox `From line' so gnus would be duped into thinking they were
incoming procmail spools, and write them to nnml groups accordingly. 

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

Harry Putnam <reader@newsguy.com> writes:

>> Yes.  It would make the Agent's storage not correspond with the real
>> server storage, meaning that we would have to implement ways of not
>> letting expiry touch certain articles, etc.
>
> But isn't that already the case?  The stuff in an agentized group can
> way outdate what is on the server.  Keeping up with that difference
> was implemented way back about pgnus-[20-21].

The real question is -- why on earth would you want to edit articles
in the Agent?  Why wouldn't you just like to be able to edit any
arbitrary article from any read-only backend?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Harry Putnam <reader@newsguy.com> writes:
>
>>> Yes.  It would make the Agent's storage not correspond with the real
>>> server storage, meaning that we would have to implement ways of not
>>> letting expiry touch certain articles, etc.
>>
>> But isn't that already the case?  The stuff in an agentized group can
>> way outdate what is on the server.  Keeping up with that difference
>> was implemented way back about pgnus-[20-21].
>
> The real question is -- why on earth would you want to edit articles
> in the Agent?  Why wouldn't you just like to be able to edit any
> arbitrary article from any read-only backend?

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?  If this were automated it would be very similar
to what I was suggesting I think.

I didn't understand your argument about cache the first time around
though so maybe just not `getting it'.  Does cache offer the other
things that go with mail backends, like complex expiry?  Editing isn't
the only thing missing in agentized messages. It would be nice to be
able to target-expire them.  Especially if someone can think of a way
to base expiry on date AND score AND readedness.

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

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.

> If this were automated it would be very similar to what I was
> suggesting I think.

Yes.

> I didn't understand your argument about cache the first time around
> though so maybe just not `getting it'.  Does cache offer the other
> things that go with mail backends, like complex expiry?  Editing isn't
> the only thing missing in agentized messages. It would be nice to be
> able to target-expire them.  Especially if someone can think of a way
> to base expiry on date AND score AND readedness.

This isn't what the Agent is for.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Harry Putnam]

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.  I guess you mean once they have been
cached, but after pressinf * on a message and then `e' I'm still told
it isn't allowed, although the message appears in
~/News/cache/group/*.

But that is what I meant by `work'.  Something more
(not sure what) still needs to happen.

>> If this were automated it would be very similar to what I was
>> suggesting I think.
>
> Yes.

Well similar yes but more work.  Do you mean creating an nndir group to
visit the cache?  But that is readonly too.  Maybe you mean to create
nnml groups of the cached groups?  Again more work is needed.

If incoming agent messages were siphoned off to a mail backend no
other work is required. Except any mail backend type activity you
might want.

>> I didn't understand your argument about cache the first time around
>> though so maybe just not `getting it'.  Does cache offer the other
>> things that go with mail backends, like complex expiry?  Editing isn't
>> the only thing missing in agentized messages. It would be nice to be
>> able to target-expire them.  Especially if someone can think of a way
>> to base expiry on date AND score AND readedness.
>
> This isn't what the Agent is for.

What isn't what the agent is for?  Targetted-expiry?  But that is just
something that comes up when you own files.  Agent is a way to own
files or at least I always used it that way.  Isn't the idea to
provide access beyond what the nntpserver allows?  Like hanging onto
them until hell freezes over...  Or do you mean the complicated
expiry decision based on three things?

Most recently, I'm suggesting diverting a copy for other uses,
leaving the agent to do what it does.  But I think to be reliable it
would have to be done at the level of intervening in the agent download.

I may have just thought of something that might take care of what I'm
after diverting messages after the fact:

Imagine a score file that scores on what ever but trips a function
that copies the scored message to a mail backend group.  Maybe this is
possible now?  All I'm really after here is to save messages that
match a certain description to a data base where they can be searched
when needed.  I don't want to do it by hand. Maybe adding certain
headers like a keyword header to further facilitate the searching once
they are in a mailbackend group.

How could one arrange it so that messages scored above default get
copied over to similar named mail group when an agent group is opened.
Maybe changing the target group name on a monthly basis.

The part about matching a certain description is just for saving space
and provide a more centrated database.  Otherwise I would just save
agent groups forever.  But they get so damned big, and require so much
overhead even just to open.  But because of their nntp status we can't
really do stuff to them.

Re: Make gnus-agent another mail backend?

[Kai Großjohann]

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.

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

I like Lars' idea a lot.  It would work in more cases, not only the
Agent.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Make gnus-agent another mail backend?

[Harry Putnam]

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.

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

Harry Putnam <reader@newsguy.com> writes:

> 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.

Ah.  I just knew there was some sub-text I wasn't getting.  :-)

> 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.

Hm...  What would you use this for?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Steinar Bang]

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

> 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.

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

I'm not the one asked, but this wouldn't make me happy.

I would like to be able to rethread nnimap articles, and I would like
the rethreading to happen on the IMAP server.

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> I would like to be able to rethread nnimap articles, and I would like
> the rethreading to happen on the IMAP server.

You can't edit IMAP messages?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@dod.no> writes:

>> I would like to be able to rethread nnimap articles, and I would
>> like the rethreading to happen on the IMAP server.

> You can't edit IMAP messages?

Not unless something has been checked into CVS very recently.

The last time the issue was up, the problem was how to do the
changes.  IMAP doesn't support editing of messages, so the only way to
do the editing, would be to download the article, delete the article
in the IMAP folder, and upload the edited article as a new article.

OK for small articles, but it could have unexpected effects if all you
wanted to do was rethread an article with a large attachment, while
connected to the IMAP server with a slow link.

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> The last time the issue was up, the problem was how to do the
> changes.  IMAP doesn't support editing of messages, so the only way to
> do the editing, would be to download the article, delete the article
> in the IMAP folder, and upload the edited article as a new article.
>
> OK for small articles, but it could have unexpected effects if all you
> wanted to do was rethread an article with a large attachment, while
> connected to the IMAP server with a slow link.

That's up to the user, though.  If it's too slow editing an IMAP
message, then it's too slow.  If not, not.  So I think nnimap should
support article editing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Steinar Bang <sb@dod.no> writes:
>
>> The last time the issue was up, the problem was how to do the
>> changes.  IMAP doesn't support editing of messages, so the only way to
>> do the editing, would be to download the article, delete the article
>> in the IMAP folder, and upload the edited article as a new article.
>>
>> OK for small articles, but it could have unexpected effects if all you
>> wanted to do was rethread an article with a large attachment, while
>> connected to the IMAP server with a slow link.
>
> That's up to the user, though.  If it's too slow editing an IMAP
> message, then it's too slow.  If not, not.  So I think nnimap should
> support article editing.

The IMAP protocol doesn't support article editing via replacing.  If
article editing is to be supported anyway, something in Gnus needs to
be done, but I never edit articles so I don't know what is expected --
if the only use would to re-thread articles, maybe something faster
than editing the article could be used.  Hm.  Perhaps doing this would
make it possible to rethread articles in nntp groups as well.

Re: Make gnus-agent another mail backend?

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> The IMAP protocol doesn't support article editing via replacing.  If
> article editing is to be supported anyway, something in Gnus needs to
> be done, but I never edit articles so I don't know what is expected --
> if the only use would to re-thread articles, 

Personally I've done two things: rethreading, and fixing MIME types
(turning application/octet-stream into something useful).

> maybe something faster than editing the article could be used.  Hm.
> Perhaps doing this would make it possible to rethread articles in
> nntp groups as well.

You're thinking of editing stuff in the agent NOV files?

Re: Make gnus-agent another mail backend?

[Bjørn Mork]

Steinar Bang <sb@dod.no> writes:
>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> The IMAP protocol doesn't support article editing via replacing.  If
>> article editing is to be supported anyway, something in Gnus needs to
>> be done, but I never edit articles so I don't know what is expected --
>> if the only use would to re-thread articles, 
>
> Personally I've done two things: rethreading, and fixing MIME types
> (turning application/octet-stream into something useful).

I often wish I could strip attachments. One of my IMAP accounts has a
ridiculously low quota.. 


Bjørn
-- 
I don't want to hear about your sexual fantasy.  

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> The IMAP protocol doesn't support article editing via replacing.  If
> article editing is to be supported anyway, something in Gnus needs to
> be done, but I never edit articles so I don't know what is expected --
> if the only use would to re-thread articles, maybe something faster
> than editing the article could be used.  Hm.

How does nnimap do the message/article number mapping?  Would nnimap
be able to preserve the message/article number mapping after deleting
the original message and inserting the edited message?

> Perhaps doing this would make it possible to rethread articles in
> nntp groups as well.

I don't think re-threading is the primary concern.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> The IMAP protocol doesn't support article editing via replacing.  If
>> article editing is to be supported anyway, something in Gnus needs to
>> be done, but I never edit articles so I don't know what is expected --
>> if the only use would to re-thread articles, maybe something faster
>> than editing the article could be used.  Hm.
>
> How does nnimap do the message/article number mapping?  Would nnimap
> be able to preserve the message/article number mapping after deleting
> the original message and inserting the edited message?

Nnimap doesn't do any message number mapping at all, it uses message
numbers from the server.  I guess adding article number mapping code
could be done, but as the saying goes, it sounds like work.  Patches
welcome. :-)

Re: Make gnus-agent another mail backend?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Nnimap doesn't do any message number mapping at all, it uses message
> numbers from the server.  I guess adding article number mapping code
> could be done, but as the saying goes, it sounds like work. 

Indeed.  Then I have no ideas.  :-/

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Make gnus-agent another mail backend?

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> The IMAP protocol doesn't support article editing via replacing.  If
>> article editing is to be supported anyway, something in Gnus needs to
>> be done, but I never edit articles so I don't know what is expected --
>> if the only use would to re-thread articles, maybe something faster
>> than editing the article could be used.  Hm.
>
> How does nnimap do the message/article number mapping?  Would nnimap
> be able to preserve the message/article number mapping after deleting
> the original message and inserting the edited message?

IMAP has article numbers, nnimap just uses them.

>> Perhaps doing this would make it possible to rethread articles in
>> nntp groups as well.
>
> I don't think re-threading is the primary concern.

Back when I was still using nnml, I used `T ^' much more often than
`e' or any other way to edit a message.  I think once nnimap supports
rethreading, `T ^' will account for a sizable proportion of the
article edits.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Make gnus-agent another mail backend?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> The IMAP protocol doesn't support article editing via replacing.

But nevertheless, WIBNI nnimap would pretend to support article
editing, by deleting the old article and creating a new one?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Make gnus-agent another mail backend?

[Simon Josefsson]

On Sun, 27 Jan 2002, Kai   Großjohann wrote:

> Simon Josefsson <jas@extundo.com> writes:
> 
> > The IMAP protocol doesn't support article editing via replacing.
> 
> But nevertheless, WIBNI nnimap would pretend to support article
> editing, by deleting the old article and creating a new one?

Yes, but IMHO only if it would work as you would expect -- that the
articles was changed on the IMAP server, and not locally to one
installation.  And nnimap provides the interface to do this, just
-request-article the article, edit it and when done, -expire the old
article and -request-accept the copy.  I guess `e' could be modified to do 
this, unless the backend supports true editing via replacing.

Re: Make gnus-agent another mail backend?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Yes, but IMHO only if it would work as you would expect -- that the
> articles was changed on the IMAP server, and not locally to one
> installation.  And nnimap provides the interface to do this, just
> -request-article the article, edit it and when done, -expire the old
> article and -request-accept the copy.  I guess `e' could be modified to do 
> this, unless the backend supports true editing via replacing.

So it would _not_ work to write nnimap-request-replace-article, which
does nnimap-request-accept-article on the changed version and then
nnimap-request-expire-articles on the old one?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Make gnus-agent another mail backend?

[Simon Josefsson]

On Mon, 28 Jan 2002, Kai Großjohann wrote:

> Simon Josefsson <jas@extundo.com> writes:
> 
> > Yes, but IMHO only if it would work as you would expect -- that the
> > articles was changed on the IMAP server, and not locally to one
> > installation.  And nnimap provides the interface to do this, just
> > -request-article the article, edit it and when done, -expire the old
> > article and -request-accept the copy.  I guess `e' could be modified to do 
> > this, unless the backend supports true editing via replacing.
> 
> So it would _not_ work to write nnimap-request-replace-article, which
> does nnimap-request-accept-article on the changed version and then
> nnimap-request-expire-articles on the old one?

No, doing so would lose information related to the message number.  I 
guess nnimap could make sure all flags stored at the server on the old 
message could be copied onto the new one, but there is other information 
that would be lost (bookmarks, scores, ...) so maybe that solution causes 
more problem than it solves?

Re: Make gnus-agent another mail backend?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> No, doing so would lose information related to the message number.  I 
> guess nnimap could make sure all flags stored at the server on the old 
> message could be copied onto the new one, but there is other information 
> that would be lost (bookmarks, scores, ...) so maybe that solution causes 
> more problem than it solves?

Ah, I see.  And maybe it is not possible to set all flags?  For
example, the \Seen flag is per-user, I think, and so an edited
message in a shared folder would be unseen for the others.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Make gnus-agent another mail backend?

[Simon Josefsson]

Kai.Grossjohann@cs.uni-dortmund.de (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> No, doing so would lose information related to the message number.  I 
>> guess nnimap could make sure all flags stored at the server on the old 
>> message could be copied onto the new one, but there is other information 
>> that would be lost (bookmarks, scores, ...) so maybe that solution causes 
>> more problem than it solves?
>
> Ah, I see.  And maybe it is not possible to set all flags?  For
> example, the \Seen flag is per-user, I think, and so an edited
> message in a shared folder would be unseen for the others.

Right.  I'm not sure what to do, but if someone does it, it would be
nice, I guess.

Re: Make gnus-agent another mail backend?

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> ... Why wouldn't you just like to be able to edit any arbitrary
> article from any read-only backend?

I would.

Specifically, I would like to be able to rethread nnimap groups.

Re: Make gnus-agent another mail backend?

[Harry Putnam]

prj@po.cwru.edu (Paul Jarc) writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
>> prj@po.cwru.edu (Paul Jarc) writes:
>>> Could the Agent be changed to use a normal mail backend for its
>>> storage?
>>
>> It does -- nnagent is just a layer on top of nnml.
>
> Are the nnml groups exposed so they could be used like normal nnml
> groups?  Would it do any harm to remove or edit articles in those
> groups?  Could nnagent use a user-specified backend instead of always
> nnml?

I tried to outline a method without knowing doodoo about how any of it
works so may be way off the wall, but it seems one could intervene
directly in the agent download and syphon those incoming messages into
an existing mail backend.  Nnmaildir may be the best candidate,
because of the robustness of its way of taking in new messages.  And
generating nov as needed.  Ditto when the messages leave town. (are
deleted)

Maybe at first just copying them over, and leaving them to go to  the
normal agent as well.  It would mean parallel (duplicate) files but
only until agent-expiry axed the agent ones.  And would allow some
experimentation until a fuller implementation with no duplication
could be worked out.

Maybe about the same thing Lars suggested with Cache, except does
cache allow all the mail backend stuff, like editing etc and
convoluted (read advanced) expiry.