--On Tue, Feb 2, 1999 5:25 PM -0600 the entity known as Pete Resnick
<presnick(_at_)Qualcomm(_dot_)Com> wrote:
I see the possibility of a large system with a huge
number of active users coming back up on the net after some period of
downtime, the subsequent flood of mail, and then the subsequent flood
of filtering.
If we can get all of the needed functionality without requiring an
implementation to store arbitrary length data to do it, I think we
should go for the simpler method.
To which Matthew Wall offers this response on Wed, 03 Feb 1999 11:43:39
-0500:
I tend to agree with Pete here, to a point.
- Always assume the worst case when planning for scalability.
- that said, it's OK to put some parameters on the initial spec that might
be considered limiting if it's within the 98% of cases bound. This isn't
dictating an implementation so much as being realistic about a running
system's practical limitations.
With respect to the original issue, I think it's important for a _script_
to be able to do multiple fileintos or the equivalent. The question of
whether to complicate things with hair-splitting semantics for multiple
commands is just one of which is the most expeditious-to-implement-and-run,
and indeed, simpler is better -- as long as (imho) it allows multiple
fileintos _somehow_. Since there's going to be a certain amount of
queue-like actions in any implementation (if nothing else, to do a proper
multi-header boolean test before deciding whether to do a file or not), I
think it's reasonable to assume within a limited scope a script might be
executed this way, without this being a requirement to infinitely queue up
multiple actions with utterly no bounds.
Larry's summary seems reasonable to me:
Actions that do not affect delivery status can be used multiple times
and in any combination with each other. In the base draft, this
actions are "fileinto" and "redirect". Site policy may limit the
number of particular actions taken.
Only one action that affects delivery status may be taken. An attempt
to run more than one such action leads to a run-time error, which has
undefined behavior. In the base draft, these actions are "keep",
"discard", and "reject".
- matt