On fre, 2004-07-30 at 16:31 +0100, Alexey Melnikov wrote:
If this helps to get Sieve variables published (I am being selfish here,
of course :-)), than I agree.
I'm sorry, but I've lost track. what should be done about it? there
are some open issues in it, but they don't seem very hard problems,
really. I apologise if I have left out criticisms, it is not
intentional, my memory isn't so good.
=== excerpt ===
0.3. Open Issues
b) this extension is particularily useful if fileinto creates new
folders on demand. [SIEVE] doesn't prohibit this, and currently
some implementations will create new folders automatically, others
won't.
[out of scope, an explicit :createfolder for fileinto should be a
separate extension. this can be closed.]
Agreed.
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.
Banning variable substitutions in body parameters may also be something
implementations want to do, but this is a somewhat different issue.
e) the numeric variables are causing many headaches since they may
change spontaneously when running tests or even _during_ actions.
I don't see this as causing real problems in practice. If you need reliable
access to these variables you need to code your tests and actions accordingly.
an alternative approach is SETMATCH ["var1", "var2", "var3"] which
stores the first three match components into the listed variables.
(an empty string as a variable name means skip storing that match.)
this approach makes REPLACEHEADER less powerful.
[this is a big change to the draft, but I think it makes the semantics
clearer and reduces the chances of pitfalls. the REPLACEHEADER magic
was too magic, IMHO (it was removed from the draft anyway, but someone
else may want something similar in the future)]
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.
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.
Ned