[Top] [All Lists]

comments on draft 01

1997-08-28 03:37:59
|      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                       , Inc.
paul(_dot_)falstad(_at_)software(_dot_)com                    805-957-1790 x520         

<Prev in Thread] Current Thread [Next in Thread>
  • comments on draft 01, Paul Falstad <=