(In the implementation I'm thinking of, where ACAP is used to store
the script on the server, the parsing happens when the script is stored,
and the error can be reported at that time, so a "bad" script will never
be executed by the filter agent. I like this.)
The ACAP server isn't required to ensure validation of the data when it
stores it. The client should validate the data, but there's no way to
enforce that requirement, and the mail server is forced to re-check the
data.
Generally speaking the mail server has to assume that invalid scripts will
appear from time to time. Suppose the ACAP server doesn't validate properly?
What then?
As such, good error handling has to be part of the server, and we need to
make sure we specify what that is.
Well, OK. Let me make my concern clear -- It makes no sense
to specify a 'support' test, which implicitly recognizes the possibility
of extensions not supported by an implementation, if you don't
at least specify the syntax that such extensions must follow.
That's true, but a support test still has value even if there are
exceptional extensions that it can't handle.
That's NOT true if the support is considered to be an assertion sort of
test. That is, if the support is there, the script is execute, and if not,
the script fails.
I think trying to support cases where scripts test for the presence of certain
features in the language is _way_ too complex and dangerous for what we're
trying to accomplish here. A simple list of the extensions used at the
beginning of the script which is then checked and the script doesn't execute if
they're not present is all we need to have.
I also don't like the compromises in language design having an extensible
language implies. We've adopted the position that the language we specify has
to be reasonably reader-friendly. And extensible languages more or less by
definition imply either syntactic rigidity (e.g., PPL, the simpler LISPs,
Forth, the simpler functional languages) or some sort of fairly sophisticated
macro facility (e.g., the more complex LISPs, the more complex functional
languages, Tex and MetaFont, ASN.1 1988). The rigidity we don't want and
the complexity we cannot tolerate.
Ned