--On Sun, Jan 18, 1998 18:51 -0500 "Tim Showalter"
<tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>
wrote:
Trying to get a list of all the ways an
interpreter can fail is futile.
I agree, not that this has prevented people from trying in the past 8-).
However, there is a distinction to be made between specifying a script
language and interpreter behavior.
If
the ACAP server can't validate the script, when does the error get
returned? If the ACAP server does validate the script, but then a runtime
error happens, what happens?
Well, I'd kinda assumed that the ACAP dataset specification would include
accomodation for footprints related to validation, i.e. script generation,
modification, and validation. Either the 'authoring' or 'runtime' agent
would have access to these footprints for relay to the user. For example, an
MTA using mail transport for setting and storing these rules might send back
a mail message, while a SIEVE client using ACAP would do a search on the
footprint attribute immediately following a store. Or something like that.
This would be neutral as to the validating party; i.e. it wouldn't exclude
something on the ACAP server from doing this validation, but requiring an
ACAP server to do the validation seems like a somewhat baroque requirement.
I think the transporting agent *should* validate the code, but there's no
way to enforce that. The filtering agent has to do validation before
running the code so that syntax errors can be weeded out -- make sure that
the filter and the user agree that the script is at least valid before
trying to run it.
Well, I still disagree. Transport's transport and oughtn't pass judgement on
data -- otherwise, you're essentially suggesting something akin to what
Keith was suggesting earlier, an independent dedicated protocol.
The user (via her/his SIEVE-writing agent) would presumably have agreed to
the syntax prior to submitting it.
Asking the transport to verify the script is good, but not complete; it's
the server's responsibility because there's no other way to even suggest
that the client will get it right.
Yes. But that comes back to the basic point: why require the transport agent
to do anything at all with respect to the validity of the script if it's
ultimately the server's undeniable responsibility to vette prior to
execution? It's redundant, and the transport would merely be acting in an
advisory capacity, anyway. (And wouldn't be able to comment on extension
validity, f'rinstance, the interpreter/server might know about).
I think if you can provide a persuasive argument that there's something
about the proposal that requires a real-time validity response, you may be
arguing for YAP (yuk).
- mw
-----------------------------------------------------------------------
Matthew Wall mailto:wall(_at_)cyrusoft(_dot_)com
Cyrusoft International, Inc. http://www.cyrusoft.com
Voice: 412 605 0499 Fax: 412 605 0705
-----------------------------------------------------------------------
Proud Purveyors of the Mulberry IMAP Email Client
-----------------------------------------------------------------------