--On Thu, Jan 21, 1999 11:56 AM -0800 the entity known as Randall Gellens
<randy(_at_)Qualcomm(_dot_)Com> wrote:
Not all implementations will be able to support multiple fileinto
actions. It depends on the environment. I suggest we state that
only the last fileinto is acted on, and create a new optional action
for copyinto.
(We could make the first fileinto the active one, but I think the
last one is much more intuitive. And while it is true that some
users may put high-priority filters first, there is no requirement or
even convention to do so. Also, a high-priority filter can always
include a stop action.)
To which Matthew Wall writes on Thu, 21 Jan 1999 17:56:36 -0500:
I see the issue with multiple fileintos, but the proposed solution of
having sort of cascading optional actions seems strange. Basically, I see
"copy" as a separate kind of option from "file" and relying on copy
actually puts burdens on the implementation to keep track of this stuff and
copy from one storage location to another; while fileinto more than one
location is its own kind of thing.
Also, even though the point is well taken about there being no requirement
or convention for making the most important fileinto first in a series,
from a parsing standpoint, it makes more sense to file-or-fail for the
first entry. This is something the user interface setting up the script
might gently remind the user about, with respect to the implications of not
following the convention.
A couple of other options:
1. Have the first unsuccessful fileinto simply halt any subsequent
fileintos in a multiple fileinto.
2. Have multiple fileintos as a separate command, separate from
singleFileinto and optional to implement. This would be morally equivalent
to a copyInto, I guess 8-). But it would make the distinction a little more
obvious, and
3. Default multiple fileintos that fail into the INBOX.
- mw