--On Thu, Jan 21, 1999 5:58 PM -0800 the entity known as Randall Gellens
<randy(_at_)Qualcomm(_dot_)Com> wrote:
So a copy action in Sieve can't be the kind of
copy you are thinking of, where the message is delivered first, then
copied from there.
So the semantics of FileInto would be: this message will be delivered
into the specified mailbox instead of the default INBOX.
The semantics of CopyInto would be: this message will be delivered
into the specified mailbox in addition.
To which Matthew Wall writes on Thu, 21 Jan 1999 21:13:39 -0500:
I guess I'm hung up on the term 'copy', but also on the need to have
multiple commands. I just don't associated 'copy' with a 'final delivery
action'. (Shades of 'Folder Carbon Copy', although that's an outgoing
action, to be sure.)
I may be reacting to this this way since we use the term rather explicitly
in Mulberry's user interface (similar but somewhat richer than Pine's
folder carbon copy), in a way which is somewhat incompatible with possibly
exposing this command name in an editable sieve script.
Anyway, let me explode the syntactic implications of the semantics you
propose above:
FileInto simply specifies the name of the mailbox for which a message
matching the filter is filed into; failure files into the Default (Rather
than INBOX, let's just call it the Default mailbox.)
'Copyinto' does the same thing, but requires more lines of a Sieve script.
Example 1:
If <subject=Sieve> and <From=gellens> then
Fileinto inbox, randymail, sievemail, potentialspammail
Example 2:
If <subject=Sieve> and <From=gellens> then
Fileinto inbox
CopyInto randymail
CopyInto sievemail
Copyinto potentialspammail
I prefer example 1, in that it's real clear that all the actions are
related.
Again, we're probably coming from different environments in terms of how
common this is. I rather think that having lengthy lists of mailboxes to
file messages into is quite useful. A common example might be a technical
question on a certain subject; one could filter mail, for instance, sent to
'info' that might go into 'support' and/or a half dozen other locations,
including shared mailboxes, personal mailboxes, mailboxes monitored by
processes, etc.
Alternatively (thinking aloud here, such as it is), let's say we had a
MultipleFileInto command with these semantics: the message is filed into
all the mailboxes, and a failure on any one fails the entire operation,
delivering it instead to the Default mailbox. That's different from a sort
of serial copying, where you might want to have it continue even if there's
one failure, without delivering the message to the Default (as long as it
successfully delivered to at least one mailbox).
Hell, am I arguing for _three_ commands here?
Fileinto --> files into one and only one, defaults to Default mailbox
CopyInto --> files into specified mailbox, if it's able to, assumes at
least one initial succesful file operation
MultipleFileinto --> files into all the mailboxes, else it fails.
Damn. I can actually see the need for all three.
- matt
PS Can we call CopyInto DuplicateInto...? It would make me happier...