Re: P followup...

Geetha Manjunath wrote:

> I think we should leave this decision of 'what is available' to the
> module writer. For example, in the case of HTTP, just knowing the
> request header (plus a preview of some data) may be sufficient for major
> decisions, however, for SMTP, we may need to look at the complete body
> (for example to figure out whether it is a SPAM). 
IMHO, spam detection should *not* be implemented in form of a rule, 
but rather as an OPES service. In the example, there would be a rule 
that says something like "if email is for Markus, invoke the spam 
detection application", but the rule itself would *not* try to 
implement spam detection.
Please let's be careful where to draw the line. My view is that we are 
*not* chartered to specify a general purpose processing/programming 
language, but a language for specifying rules that are used to 
described when certain actions are invoked (as opposed to encoding the 
action itself inside the rule) - the rules language has a very limited 
scope, which might be blurry and not always clear, but we should be 
sensitive about how far we want to go with the rules language.
For my taste, for example, IRML had all the functionality required. We 
decided to drop IRML in favor of "P" not because of limited 
functionality, but because of syntax preferences. As such, maybe the 
functionality provided by IRML can be a guidance on what we need to 
build into "P" - whenever we feel more flexibility/functionality needs 
to be build in, we should very carefully discuss this.
-Markus