ietf-mta-filters
[Top] [All Lists]

Re: variables extension redux

2004-08-04 01:15:42

On tir, 2004-08-03 at 10:51 -0700, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
d)   the EDITHEADER draft includes an action that needs the unexpanded
     string to be passed to the procedure, since the action first per-
     forms matching which may influence numeric variable references in
     the argument.  this is can be seen as a layering violation, and the
     variable draft should state explicitly whether such extensions are
     possible.

Vacation also needs access to the unexpanded strings for its internal hash
computations. This means that implementations need to allow for argument
evaluation to be done in two steps, first get the argument, then expand it.
Given that you have to allow for this anyway I don't see a problem with 
letting
future extensions do this sort of thing explicitly.

"vacation" is a good example.  perhaps a implementor's hint is off-topic
for the draft, but I suggest adding this to the end of 3 (just after the
next excerpt), before 3.1.

        Tests or actions in future extensions may want to access the
        unexpanded version of the string argument and do the expansion
        after, e.g., setting variables in its namespace.  The design of
        the implementation should allow this.

or more tersely:

        Future extensions may require access to the unexpanded version
        of the string argument.

(it's a given the implementation provides an internal function for
expanding a string...)

Banning variable substitutions in body parameters may also be something
implementations want to do, but this is a somewhat different issue.

right, there is already this wording:

        Strings where no variable substitutions take place are referred
        to as constant strings.  Future extensions may specify that
        passing non-constant strings as arguments to its actions or
        tests is an error.

[SETMATCH]

This would be easy for me to implement but I really don't care for it. In
particular, I find

     setmatch ["", "", "", "foo"];

to be pretty awful.

I'd feel differently if this actually solved the value changing problem during
compound tests, but it doesn't.

okay, I'll kill the issue and stick to numeric variables unless someone
else weighs in.

     a related question is what happens when a match fails.  the draft
     currently says that the numeric variables are reset, but this may
     be inconvenient.

I'd prefer to have the values remain unchanged, but I can live with it
either way.

I'm currently favouring the same, mostly due to precedence of this
behaviour in Perl.  I note that Sendmail claims to have implemented
"variables" already, and this is one of those small things which can
bite script writers if we change it around, although I think most
scripts will be straightforward and use a "SET" immediately after the ":
matches".  My conclusion is that we can do the change.

-- 
Kjetil T.


<Prev in Thread] Current Thread [Next in Thread>