Date: Tue, 26 Jan 1999 14:39:35 -0800
From: Randall Gellens <randy(_at_)qualcomm(_dot_)com>
At 10:30 PM -0800 1/25/99, Ned Freed wrote:
I have a far bigger problem with the notion that somebody advanced
of having multiple keeps deliver multiple copies of a message. This
is unimplementable more often than not, as quite a few delivery
schemes do duplicate address elimination, duplicate message
elimination, or both. I cannot support such semantics, and I doubt
I'm alone in this.
I don't think it makes sense (it isn't desirable) for multiple keeps
to be different than a single keep.
Ned's saying it isn't possible. That rules out desirability.
Is there any case where writing a message to a single mailbox twice is
useful?
I do agree that the rule needs to be that the default is only taken when no
other action of any sort, not just ones on a short list, has been.
So if a script only does a reply, is the message kept or discarded?
Neither is specified, so one has to be the default action.
Reply is not in draft 06, 05, or 04, because in LA, it was decided that
reply was dangerous without some sort of vacation-style protection
(limit number of replies in a single time period).
However, "no other action of any sort" would imply that it is discarded.
(I wouldn't mind having a vacation command that also implied a keep, but
that's not what we're talking about here.)
What's wrong with saying that some actions affect delivery status,
and other actions don't?
If you're having these things in a UI, it doesn't matter what we say, we
can (we have to) assume the UI will just get it right.
But for the people designing the UI, and the people implementing scripts
using a text editor, the fewer special cases, the better.
It is much easier to explain this:
"A message that generates no actions gets filed into your INBOX."
than this:
"A mesasge that generates no delivery actions gets filed into your
INBOX. Delivery actions are ones which change the disposition of the
message, and they are reject, forward, and fileinto."
--
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>