Keeping cached (*) mail articles in the backend. Bad idea?

Keeping cached (*) mail articles in the backend. Bad idea?

[Rob Browning]

When using total expire, which I'm playing with in some groups right
now, there are some cases where I'd like to use caching to keep a
particular article around indefinitely.  This gives me the one extra
non-expirable article state I'd like to have (i.e. read and cached).

The problem right now is that caching an article means that I can no
longer presume that all my mail articles for a given group will be in
a single directory (if I'm using nnml and I want to use shell tools to
do stuff, etc.).

I was wondering (and perhaps it's just a monumentally bad idea), if it
might be possible to add support to allow cached mail articles to just
be stored in the normal mail folder (i.e. don't move them, but don't
let them be expired) rather than putting them into the cache
heirarchy...

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: Keeping cached (*) mail articles in the backend. Bad idea?

[Kai.Grossjohann]

Rob Browning <rlb@cs.utexas.edu> writes:

> When using total expire, which I'm playing with in some groups right
> now, there are some cases where I'd like to use caching to keep a
> particular article around indefinitely.  This gives me the one extra
> non-expirable article state I'd like to have (i.e. read and cached).

Hm.  You can mark the article dormant (?) or ticked (!) -- both of
these won't be expired.

If you need one more article state than allowed by total-expire, I
suggest that you use auto-expire instead.

With total expire, you have:

  - unmarked            SPC
  - ticked              !
  - dormant             ?
  - read = expirable    R / O

Only read/expirable articles will ever be deleted.

With total-expire off (possibly auto-expire on), you have:

  - unmarked            SPC
  - ticked              !
  - dormant             ?
  - read                R / O
  - expirable           E

Only expirable articles will ever be deleted.

Do you need more marks than this?  I think user-defined labels are
still on the todo list (and have been there for a long time).

kai
-- 
Life is hard and then you die.

Re: Keeping cached (*) mail articles in the backend. Bad idea?

[Rob Browning]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Hm.  You can mark the article dormant (?) or ticked (!) -- both of
> these won't be expired.

Mostly I just thought that having cached mail articles stay in the
mail folder might be a bit more elegant, certainly a bit less
redundant, but I could imagine that this might add too much complexity
to the expire (and other) code.

> If you need one more article state than allowed by total-expire, I
> suggest that you use auto-expire instead.

I could, but of course that prevents me from being able to play with
adaptive scoring (at least that was my understanding).

I think we've probably talked about this before on (c.e.g.), so I
don't want to waste your time again, but the short version is that
after listening to some pretty convincing arguments on the newsgroup,
I came to the conclusion that total-expire would be quite a bit better
than my current arrangement.  Accordingly, I was trying to move in
that direction.

The (4) states I wanted were unread, urgent, read/archived,
read/needs-attention/but-not-urgent.  With total-expire you really get
only three permanent states.  Presuming I was going to use
total-expire, I realized I could get the fourth state by using
cached/read articles.  Unfortunately, that had the ugly side effect of
moving all those articles somewhere else.  Since I use grep and
friends on my nnml groups reasonably often, it would be awkward to
have to specify two directories in every command.

> Do you need more marks than this?  I think user-defined labels are
> still on the todo list (and have been there for a long time).

User defined labels sound really nice as long as you can either tell
Gnus what their expiry behavior should be.  I'd offer to try and do it
myself, but I'm not sure I have the time right now, and I'm not an
elisp whiz.  I have a lot more experience with scheme and common-lisp,
though if Gnus doesn't delve to deeply into elisp eccentricities, I
might be all right...

Anyway, thanks to all for a wonderful tool, only a fraction of which
I've had the opportunity to learn.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: Keeping cached (*) mail articles in the backend. Bad idea?

[Kai.Grossjohann]

Rob Browning <rlb@cs.utexas.edu> writes:

Yes, you need total-expire for using adaptive scoring.  So my
suggestion is not a real help for you.  (I pretty much forgot about
that other discussion, thanks for the reminder.)

> User defined labels sound really nice as long as you can either tell
> Gnus what their expiry behavior should be.

Well, I presume that they would be orthogonal, i.e. you can have a
message which is expirable and labeled `foo', and another message can
be ticked and labeled `foo'.

kai
-- 
Life is hard and then you die.

Re: Keeping cached (*) mail articles in the backend. Bad idea?

[François Pinard]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> Rob Browning <rlb@cs.utexas.edu> writes:
> Yes, you need total-expire for using adaptive scoring.

I tried adaptive scoring for a while, and it did not hook me :-)

But I do not remember that there is a relation with total expiry.  How comes?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Keeping cached (*) mail articles in the backend. Bad idea?

[Kai.Grossjohann]

François Pinard <pinard@iro.umontreal.ca> writes:

> But I do not remember that there is a relation with total expiry.
> How comes?

Without total-expire, all expirable articles are marked E.  With
total-expire, catching up marks articles with gnus-catchup-mark.
Adaptive scoring needs the difference to work.

I think.

kai
-- 
Life is hard and then you die.