Lee, Lily, Andre,
thanks for the ID on OPES policy requirements - excellent starting
point! Just a few minor comments that came to mind, which maybe we can
address in the session tomorrow:
Section 3.2.2 says that "...some of the environment variables may be
numeric and, therefore, require some arithmetic operations". Section
5.2 says that "... all rule conditions as well as attribute values
MUST be treated as string values so that the rule matching can be done
by simply comparing the string values...". This sounds like a conflict
as environment variables can be part of rule conditions. In general,
it would be interesting to discuss the need for arithmetic operations
in rule conditions - which operations might be required, or whether
all could be done using sets of threshold enumeration (as described in
Section 3.2.2).
Section 5.2 says that rule conditions can possible include protocol
body values. Previously, we had some discussions on whether rules
should be restricted to protocol headers only (for performance reasons
- might be very expensive to allow parsing of message bodies for rule
matching). Maybe be can reach consensus on either of both.
Section 3.1.3 raises a fundamental question - whether the execution of
an action may lead to side effects altering the result of subsequent
rules. This might be the case if matched actions modify environment
variables (e.g. load) or message properties (e.g. content type). The
answer to this question has great impact on how rule systems will be
implemented. If subsequent rules might be effected, matched actions
have to be executed before evaluating subsequent rules, which
complicates implementation and will have performance impacts. If
modification of message properties and/or environment variables is NOT
allowed, this limits the application space (as pointed out in the
second alternative of Section 3.1.3). Basically, it's sort a trade-off
between functionality/flexiblity and performance. Would be interesting
see what the general feeling is on this issue.
At the end of Section 3.1.3, you mention the possibility of allowing
two types of rules, basically mapping rules in one of the two
alternatives mentioned above. We thought about something similar when
looking into OMML. OMML let's you specify whether a service can modify
message properties. A rule engine/rule compiler could use such
meta-data (on services) to determine which rules could be "batched
together", and which actions would have to be executed before
evaluating subsequent rules. For example, if the rule engine would
know that the actions associated with certain rules will never have
impact on subsequent rules, the rule engine could start evaluating
these rules in a single parse, and then execute all matched actions.
After this step, the rule engine would continue to evaluate rules,
whose actions might have impact on subsequent rules - step-by-step.
So, the proposed alternative at the end of Section 3.1.3 might an
interesting one, but would require information about the services that
might be triggered by matching rules.
Just a few thoughts...
Thanks,
Markus