suggestion for expiry

suggestion for expiry

[Max Froumentin]

I like gnus for its ability to wait before deleting expirable mail
messages (nnmail-expiry-wait-function, etc.).  In my mail groups,
expiry length is set to 30 days. When I keep messages ticked for more
than a month, and then I mark them expirable, they are deleted
immediately. Am I the only one to be bothered by this?

May I suggest that expiry be based on another date than the message's
'Date:' field? Rather, another field storing the date of the last time
the message was read seems to me more appropriate.  What do people
think?

Max.

Re: suggestion for expiry

[Toby Speight]

Max> Max Froumentin <URL:mailto:masmef@maths.bath.ac.uk>

0> In <URL:news:ptvk8rlq65b.fsf@scratchy.maths.bath.ac.uk>, Max wrote:

Max> May I suggest that expiry be based on another date than the
Max> message's 'Date:' field? Rather, another field storing the
Max> date of the last time the message was read seems to me more
Max> appropriate.  What do people think?

I'm not sure another field would be necessary for nnml or nnmh: they
could use the access-time from the filesystem (on Unix-like filesystems;
I don't know whether other OSes have a comparable concept).

<me-too>If it were implemented, I'd be happier.</me-too>

Re: suggestion for expiry

[Max Froumentin]

I don't think that using the filesystem's access-time would work on
individual articles in nnfolders.

Max.

Re: suggestion for expiry

[Simon Josefsson]

Max Froumentin <masmef@maths.bath.ac.uk> writes:

> I don't think that using the filesystem's access-time would work on
> individual articles in nnfolders.

Gnus use a date from X-Gnus-Article-Number in nnfolder's when expiring
articles, it could be modified to update that date to indicate when
the article actually became eligeble for expiring.

That would even work, using access-time in nnml groups is not a good
idea -- articles might not be expired at all due to backups, glimpse,
filesystems where atime=mtime etc. OTOH and similar to nnfolder, one
could have nnml touch files when a article actually became eligeble
for expiring.

I'm not saying it's a good idea though, I've no problem with the
current behaviour.

Re: suggestion for expiry

[Thomas Lofgren]

>>>>> "Max" == Max Froumentin <masmef@maths.bath.ac.uk> writes:

    Max> I like gnus for its ability to wait before deleting expirable
    Max> mail messages (nnmail-expiry-wait-function, etc.).  In my
    Max> mail groups, expiry length is set to 30 days. When I keep
    Max> messages ticked for more than a month, and then I mark them
    Max> expirable, they are deleted immediately. Am I the only one to
    Max> be bothered by this?

I find it very convenient.  If I want to save the article after
unticking, I just mark it as read instead of expired.  Typical example
is a message on bugtraq that seems interesting.  I tick the article
until I have time to look into if my systems are vulnerable, and when
I'm done I expire it.  If that means th article is deleted right away,
then that's exactly what I want.  After all, I had plenty of time to
look at it.

    Max> May I suggest that expiry be based on another date than the
    Max> message's 'Date:' field? Rather, another field storing the
    Max> date of the last time the message was read seems to me more
    Max> appropriate.  What do people think?

This would be a very bad idea, because then Gnus behavior depends on
the configuration of *another system*.  If I set my date back a few
weeks/months/years, I can have my mail expired on your machine right
away.  Arrival time would be more interesting, since then you're only
trusting your own system.

Tom
-- 
T. Lofgren <lofgren@sics.se> - Wherever I lay my .emacs, that's my ${HOME}
"Hear that, Mr Anderson?  That's the sound of inevitability." - Smith

Re: suggestion for expiry

[Sam Falkner]

Max Froumentin <masmef@maths.bath.ac.uk> writes:

> I like gnus for its ability to wait before deleting expirable mail
> messages (nnmail-expiry-wait-function, etc.).  In my mail groups,
> expiry length is set to 30 days. When I keep messages ticked for
> more than a month, and then I mark them expirable, they are deleted
> immediately. Am I the only one to be bothered by this?

This bothers me too.

> May I suggest that expiry be based on another date than the
> message's 'Date:' field? Rather, another field storing the date of
> the last time the message was read seems to me more appropriate.
> What do people think?

I think that `the time it was marked expirable' would be best; or,
have gnus figure out `the last time it was read' via some method other
than atime (i.e. an X-last-read header that it maintains).  I'd hate
to have a cron job that did greps in your folder keep articles from
ever expiring.

- Sam

Re: suggestion for expiry

[Toby Speight]

Simon> Simon Josefsson <URL:mailto:jas@pdc.kth.se>

0> In <URL:news:iluiu74bxrp.fsf@unikabox.pdc.kth.se>, Simon wrote:

Simon> Max Froumentin <masmef@maths.bath.ac.uk> writes:

>> I don't think that using the filesystem's access-time would work on
>> individual articles in nnfolders.

That's the reason I only mentioned nnml and nnmh ;-)


Simon> Gnus use a date from X-Gnus-Article-Number in nnfolder's when
Simon> expiring articles, it could be modified to update that date to
Simon> indicate when the article actually became eligeble for
Simon> expiring.

Perhaps it could use an Expires header (consistent with news article
format now), with the caveat that when it's changed, it's never made
earlier.  I think some other MUAs generate Expires headers (I'll have
to test this tomorrow, as I'm on my way out now), and so this would
allow those to work.  It would require some checking on incoming mail
(at split time?) to enforce upper and lower bounds on sender-supplied
expire times, with nnmail-expiry-wait being the default.  Then any
significant change to an expirable item pushes the expiry date out.

This has the benefit that the expiry date is visible to the user, too.

Re: suggestion for expiry

[Colin Marquardt]

* Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> Perhaps it could use an Expires header (consistent with news article
> format now), with the caveat that when it's changed, it's never made
[...]
> This has the benefit that the expiry date is visible to the user, too.

Yes, and I would find that last feature really useful.

Colin