You can flame me if I'm really off-base here :-)
Hopefully, the variables being discussed here are not named/dedicated to
specific conditions or values (examples mentioned earlier: network b/w,
system load/cpu load, # of client connections, ....).
When we talk about introducing state variables that reflect run-time
conditions etc , we also need "limits" (thresholds above/below which rules
trigger different actions than the "normal" ones) to be
defined/stored/updated as systems/services get updated.
Can we leave these in abstract forms and define a "generic" set of variables
and a pair of "limit" values for each of the variables (assumption: if you
cross the lower or upper limits, there are "abnormal" actions to be taken)?
As I said earlier, if the above doesn't make sense, I'm game to be flamed.
Regards,
- Rama
*******
-----Original Message-----
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
Sent: Tuesday, June 12, 2001 4:22 PM
To: Yang, Lily L
Cc: Maciocco, Christian; 'Gamze Seckin'; 'ietf-openproxy(_at_)imc(_dot_)org'
Subject: Re: Efficacy of rule specification, processing
"Yang, Lily L" wrote:
Many of the dynamic behavior can be achieved with a set of carefully
written
rules -- the rules are static but the run time matching will result in
dynamic behavior accordingly.
And this run time matching requires a set of state variables - the
question was which and how many. For example, should "local system
load" be a run time variable for the rule language?
-Markus