| An extension for regular expressions will be written. While
| regular expressions are of questionable utility for most users, the
| programmers writing implementations desperately want regular
| expressions.
I'd suggest "contains-re" for this.. "matches-re" might be a more obvious
choice, but it implies that the regex is anchored at the beginning
and end of the string. I can start the regex with ^ and/or end it
with "$" if I want that.
| The following example will fail on any server that does not implement
| the extension known as DWIM.
|
| Example: require "dwim";
| if header ("subject") contains-nocase ("the secret message")
| {
| dwim blurdybloop body;
| } stop
|
| OPEN: I have serious concerns with require; it makes it impossible to
| separate parsing from evaluation, and introduces some awkward
| cases. For instance, a script "if size under 1 { require "foo";
| do_foo; } else {... }" Even if the test will never happen, this
| require will prevent the script from working. Just support
| seems to make more sense.
It seems like "require" lines should be at the top of the script, and
should be processed as part of parsing. If the extension is not there,
just forget the whole thing. If we want to do anything fancier, I think
we'd need to specify explicitly how scripts should "fail" at run-time if
the extension isn't there (log an error? notify the owner of the
mailbox? assume "normal"?), and possibly provide some way for the
script to recover from the lack of the extension (perhaps use an alternate
mechanism), but I think this will make things more complex than they need
to be.
A script that works on some incoming messages and fails on others is
useless. I think the user should not be allowed to install a script that
requires unsupported extensions for some possible inputs; the server
should treat this as a parse error, and preferably notify the user right
away when the script is submitted (if the implementation supports that).
| [OPEN: This section is probably incomplete. I am not sure that the
| right answer is to make it easy to refuse messages, but secretly keep a
| copy. Should bounce prevent all other actions from taking affect?]
I think so, since a DSN is an official notification that the message
was not delivered.
| 5.1. all-of
[...]
| 5.2. any-of
is there a reason "and" and "or" were not considered here? They seem a
lot more readable and easy to use, especially for the novice.
| If a header listed in the header-name-list argument exists, it
| contains the null key (""). However, if the named header is not
| present, it does not contain the null key. So if a message
| contained the header
|
| X-Caffeine: C8H10N4O2
|
| these tests on that header evaluate as follows:
|
| header ("X-Caffeine") is ("") => false
| header ("X-Caffeine") matches ("") => false
| header ("X-Caffeine") contains ("") => true
If a message contains the headers:
Received: foo
more foo, on a continuation line
even more foo
Received: bar
then what is the string value of header("Received") ? Does
header ("Received") matches ("*foo*bar*") evaluate to true?
--
Paul Falstad Software.com, Inc.
paul(_dot_)falstad(_at_)software(_dot_)com 805-957-1790 x520
http://www.ttinet.com/pjf/ http://www.software.com/