Rereading draft-melnikov-sieve-external-lists-01 the main idea that came
to my mind is that ":list" adds one more (unnecessary) dimension. In
case of "header", "address" and "envelope" test, their last parameter so
far is a string-list:
address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list>
header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
With ":list" added the last parameter will be altered from "list of
strings" to a "list of list of strings".
Not really, it's a list of external lists.
At the same time mixing
"internal" and external lists gets more complicated than necessary. For
doing a check "if a mail does not come from my three girlfriends, or my
company, then reject it" it would be necessary to write
if anyof(envelope "from" ["g1", "g2", "g3"],
envelope :lists "from" ["my-department", "our-partners"]) {
reject
":P"; }
I actually prefer this. Rather strongly.
I think it would be better to allow references to lists in any
string-list, which expands the references, so that the string-list can
be used normal. What about replacing :list "my-pets" with L{my-pets},
hence the above check would be rewritten as
if envelope "from" ["g1", "g2", "g3", L{my-department},
L{<our-partners}] { reject ":P"; }
Well, first of all, what you're proposing is a syntax change to the core
language. That's unacceptable IMO.
I'm not sure you can get around this problem in a reasonable way - the
obvious
trick to try is to extend things to support "list" variables. Asuming
this can
bge made to work, it certainly has things going for it - it lets you do
things
like pull in a list, modify it in fairly complex ways, and then check stuff
against it.
However, the problem that arises if you do this is that this is a really
awkward fit into existing implementations (ours at least and I suspect
others
too). The problem is that things are geared around first evaluating list
constructs and then checking them, not the other way around. So what if
that
list expands into 1,000,000 addresses. Or more to the point, what if the
list
is defined in such a way that the only acces you have is a membership
check;
there's no way to extract the list? It' still possible to implement this as
list variables - I think - but it gets really nasty really quickly.
In this way only the definition of string-list has to be changed. The
test envelope, address and header stay untouched. For "redirect" one
has just to write that it accepts now string-list instead of just
"string".
I'm certainly in favor of having the ability to do list tests in other
contexts, but my proposal is to match :list a new MATCH-TYPE, with all
that implies.
Ned