Subject: Re: Language for conflicting actions

From: Pete Resnick <[email-masked]>
Date: Tue, 2 Feb 1999 17:25:21 -0600

On 1/28/99 at 6:00 PM -0500, Tim Showalter wrote:

> This isn't very good.  The best that you can do is do whatever happens
> first, and I don't consider that to be desirable.

I don't see a particular problem with that sort of logic flow. It 
could be done other ways, but what's the problem with "do the first 
one"? It certainly has an implementation simplicity advantage.

> I don't buy that at all.  I cannot imagine how a list of actions (which
> will typically be one per message and seldom more than five per message)
> could cause massive scaling problems even on the largest of central
> servers.

Statements like the above send up a red flag for me; anyone's 
inability to imagine a particular scaling problem doesn't strengthen 
my confidence. 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.

pr
--
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: Matthew Wall <[email-masked]>
Date: Wed, 03 Feb 1999 12:14:27 -0500

--On Tue, Feb 2, 1999 5:25 PM -0600 the entity known as Pete Resnick
<[email-masked]> wrote:

> I see the possibility of a large system with a huge 

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