----- Original Message -----
> -------- Original Message --------
> Subject: Re: [pcp] RFC - pmie "ruleset" extension
> Date: Tue, 24 Jun 2014 14:05:35 +1000
> From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
> To: Nathan Scott <nathans@xxxxxxxxxx>
>
> On 24/06/14 09:44, Nathan Scott wrote:
> > ...
> > One issue was the way there isn't just true or false, there's also "maybe"
> > (first sample for a counter, or host is down) - what would be the approach
> > there? Would it just fall through into that final else catch-all branch?
> > Heh, that would be the one that says "OK" above? ;) Might need some other
> > syntax for that case?
>
> Hmm had not thought of that. Let me "think out loud" ...
>
> Let's assume there are 3 rules (so no else <action>) part ... now
> composite ruleset behaves like a giant disjunction on the 3 rule
> predicates, so the ruleset evaluates to a boolean. The 3-state boolean
> logic we use dictates that the ruleset will be TRUE as soon as one
> predicate is TRUE and FALSE if all predicates are FALSE ... so if no
> predicate is TRUE and some are FALSE and some are DUNNO (aka "maybe")
> then the ruleset will have the value DUNNO.
*nod*
> So I need 2 optional clauses after the set of rules ... the exiting ELSE
> matches the FALSE case (but ELSE may not be appropriate semantically
> now) and I need some other keyword for the DUNNO case.
Perhaps it will help to think of it more like an exception-handling model
(so a keyword like "except" alongside the "else" clause to catch any kind
of exception, in any part of the if/else/... evaluation). Its a bit like
that, since the trigger for DUNNO can be all sorts of whacko things, and
for the most part they're exceptional things (lost connections, not enough
data yet, and so on).
cheers.
--
Nathan
|