Geetha Manjunath wrote:
* Rule Specification : The filtering services themselves would be provided by
vendors (say, virus scanners) while the configuring conditions (rules) will
be described/specified using the 'P' rule language.
Agreed.
* Writing simple filters/actions: While modifying a message to be able to
call several commoditized filters may be one of the examples (Alex), I would
see the need for writing actions more when the actions themselves are very
simple - may be to just put some additional authentication controls onto
services, where the OPES processor would just return a 40x response.
These functions are services themselves and should be invoked by the
rules, rather then trying to "programm" them in the rules.
If a function like "adding of authentication controls" is needed, a
little service doing this can be written, and a rule can be specified
to invoke this service.
* Writing modules in 'P': Since a set of rules themselves may need to be
reused many a times, we may want to create customized reusable modules in 'P'
Thats sounds worthwhile to consider (but already goes beyond the
charter discussion perse, I would assume).
(d) defining mechanisms by which a user can communicate rulesets to the OPES
processor.
Such mechanism is needed (one might default to existing ones), but out
of scope of the WG.
-Markus