This will probably be the default behavior of devices having requests load
balancing capabilities without requiring a rule.
I'm not against requiring state variables. The issue I see are:
- What will be the scope, e.g. network conditions, internal I/O conditions,
CPU load, ...
- Rule system will have to support arithmetic expression to do so or very
limited otherwise.
- Rule module can be written by independant parties. Are we requiring all
the OPES devices to provide network monitoring, I/O monitoring capabilities,
and what will be the default behavior for the one which don't provide the
feedback information.
Christian
-----Original Message-----
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
Sent: Monday, June 11, 2001 4:52 PM
To: Maciocco, Christian
Cc: 'Gamze Seckin'; 'ietf-openproxy(_at_)imc(_dot_)org'
Subject: Re: Efficacy of rule specification, processing
"Maciocco, Christian" wrote:
It looks like that by inserting state variables about
external environment
into the rules we're expecting the OPES device to control
services behavior.
I think that the OPES device should instead only decide
whether or not a
service needs to be launched and have the service itself
take care about
adapting to dynamic behavior, for example by communicating
the required
information to the service itself.
Hm, what about a scenario in which the same service is available
locally (i.e. on the OPES device) as well as remotely (i.e. on a
callout server). In this case, it would be nice to have a something
like "if my local system load is below a certain threshold, I call the
local service, otherwise I use a remote callout". How would you
implement this if only the service itself takes care about adapting to
dynamic behavior? And, no, I do NOT like the idea of chaining multiple
services :)
-Markus