[Top] [All Lists]

Re: Sieve extension to expire mails?

2004-03-12 17:16:49

On Fri, Mar 12, 2004 at 03:13:51PM -0800, 
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:

Sure it does. Folders normally retain messages until they are deleted.
This changes that semantics rather completely, don't you think?

I don't think so, and that's an opinion that I was trying to convey.
Perhaps there's a distinction centering around "deleted by whom?"

Yes, and it is a very significant one. If I have a specialized client that
prowls through some set of folders and deletes things based on some criteria or
other, its operational parameters are by definition a client concern.  Clients
the semantics and so the issue of consistent semantics for store-based deletion
doesn't arise.

If, on the other hand, a store implements some sort of message expiration
system, it almost certainly will be provided to multiple users who will  want
to use multiple clients to control and manipulate the facility on multiple
servers. Failure to nail down the semantics properly is likely to lead to
problems -- messages won't be deleted when they should have been, and worse,
messages might be deleted when they should not have been. One of the reasons we
have standards is to try and prevent this sort of thing from happening.

It is entirely reasonable to talk about using sieve to control either
a client or server side expiration facility. But a client side facility
would logically be controlled through the use of private headers or
annotations or something similar. The only thing that would need to
be standardized in this case is the means to add headers or annotations
or whatever in sieve.

A server side facility, on the other hand, needs to have the server
side semantics nailed down first. I have alredy explained why I believe
this is the case in considerable detail.

attitude is that the owner of a mailbox could legitimately instruct a
delivery agent to manipulate that mailbox as part of delivery.  One of
those instructions could be "delete the oldest message [under some
condition]".  I see no philosophical difference between that
instruction and manually hitting the 'd' key.  This introduces no new
storage semantics nor any new operational semantics.  It does wrap up
a few primitive operations into a higher level function, but that
doesn't make those operations new.  (Making them more granular would
actually be to my liking.)

Just me, I guess?

It certainly is not a view I share, nor is it a view that I feel is
likely to lead to a successful sieve extension. Again, I have
explained why I think this is the case.