On 2012-06-14 00:55, Phil Pennock wrote:
> On 2012-06-13 at 21:42 +0100, Jeremy Harris wrote:
>> accept - OK - true + message
>> defer - DEFER - forced fail
>> deny - FAIL - false + message
>> oops - ERROR - non-forced fail
>
> Makes sense to me.
>
>> (though I don't see any way of using the string result *and* the
>> boolean result from a single call at present, one might happen in the future)
>
> This is the advantage of the conditional, it can just set $value, a
> variable which is already used generically like this.
Hmm. This gets ugly on a couple of counts.
- If it's only available as a conditional then you
can only use it in a conditional context - which is
a pain when what you really wanted was the expansion.
- OK, perhaps we support both methods?
- Syntax as a conditional doesn't easily handle variable
numbers of arguments:
${if <cond> {yes}{no}} has troubles with the difference
between <cond> == <acl {name}> and <cond> == <acl {name}{arg}>
(is {yes} an arg for the acl or for the if?)
- wrap <cond> in { } ? ugly, but matches condition saslauthd
- don't wrap name or args in { } ? how to parse?
- wrap name + args in { } but space-sep within?
e.g. ${if acl {name arg1 arg2} {yes}{no}}
also nonstandard, but matches acl modifier "acl = name arg1 arg2..."
I was partway though coding the last option when I noticed saslauthd.
--
Jeremy
