Date: Thu, 28 Jan 1999 14:43:20 -0800
From: Randall Gellens <randy(_at_)qualcomm(_dot_)com>
Note that I'm not saying you can't run the script before parsing it.
I'm saying you have to queue up actions before doing any. That's pretty
easy to implement, even if you sprinkle in the evaluation code in with
the parser -- you just save up a list of all the stuff you're gonna do
and sanity check it before running it.
You can prevent mutually exclusive actions by keeping a flag as to
which ones you've done; you don't need to queue them all. So you
could parse the script first, for example, then while executing it
hit a "forward" statement and do it (and set the "forwarded" flag),
then later on hit a "reject" and issue a run-time error/warning that
it was ignored.
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.
Saving up a list of everything you're going to do could force an
implementation to use more memory or have scaling problems,
potentially.
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.
The cost of running Sieve in the first place will be orders of magnitude
higher than queueing up actions.
If a script executes multiple forwards, or replies
(assuming that is accepted as an extension), the execution agent
could be forced to dynamically allocate a potentially unbounded
amount of memory to keep all the actions (including text).
This is not very important, really. After all, if the number of headers
is large, an implementation could be forced to allocate a potentially
unbounded amount of space for that, too. Same goes for length of
the script.
As a server programmer, I don't see an implementation problem here at
all.
--
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>