Markus Hofmann wrote:
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.
While there does exist a 'thin line' between spam detection using just
rules (if sender contains blah) and invoking a complete spam detection
service, I was definitely NOT assuming that P does the complete spam
detection. However the following, I believe, brings in the need for P to
be able to have a handle to the request/response:
* The fact that we are talking about mandatory support for a special
Services module that has methods for executing OPES services (applyOne),
binds us to provide more details about the interfaces expected from this
Services module - one side to the interpreter, the other side being the
OPES service.
4. Interpreters MUST supply two modules named Core and
Services. The Core module contains members for manipulating built-in
P object types such as integers and strings. The Services module
manages OPES services.
5. Services module contains basic attributes and methods for
searching
and executing OPES services:
* The example below makes some assumptions on the interfaces that the
service itself needs to provide.
service := Services.findOne("opes://svs/tran/german/french");
service.toDialect("southern");
Services.applyOne(service, Http.request.headers);
* Putting the two together and extrapolating, we see the need for a call
of the form:
Services.applyOne(spamSevice, SMTP.body)
Thus my comment ...
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.
I agree, that IRML did have most of the things needed from a HTTP
perspective - with one of the main limitation (from usage perspective)
being no support for expressions. It was also extremely difficult to
express complex conditionals (AND, OR , NOT and others) - ofcourse, you
could classify that to be a syntax issue... Due to the simplicity of
IRML, we probably could even claim it to be applicable for other
protocols ..
Now, if we want to limit the scope of 'P' to just a re-syntaxing of IRML
and making the rule language protocol agnostic, that is a decision of
scoping again, I guess.... Not sure how many would want it that way..
Not me ;-)
-Markus