On Tue, 9 Dec 2003, Markus Hofmann wrote:
IMHO, spam detection should *not* be implemented in form of a rule,
but rather as an OPES service.
If OPES service invocation is indistinguishable from a P module call,
then the above point becomes unimportant from P point of view. We
simply do not have to decide at P Core level (which is good). I
believe that the discussion with Andre concluded that making service
invocation indistinguishable from a P module call is the right way to
go.
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.
IMO, the line here is too thin to define:
if (msg.from() contains "Markus") {
callSpamDetectionService(msg);
}
versus
if (msg.from() contains "KnownSpammer") {
callMsgBlockingService(msg);
}
both rules implement a portion of spam handling algorithm. Both are
equivalent from P Core point of view, IMO.
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)
I agree. The action itself is hidden in a P call, which can be a
callout service with a P interface or an internal service with a P
interface. The latter is particularly indistinguishable from anything
else a P module provides.
- 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.
The scope is indeed one of the most difficult/important questions
here. It may seem simple on the surface (as usual), but scope effects
become crucial once we start to dig deeper. We have already seen that
with OPES Communications, OCP Core, and HTTP Adaptations drafts!
In fact, my current inability to estimate P draft completion date is a
result about poorly defined scope. With the renewed interest in P, and
several "grand ideas" related to P, I am no longer certain that
current P draft has the right scope. Hence, I do not know the amount
of work that remains to be done.
Alex.
P.S.
For my taste, for example, IRML had all the functionality required.
IRML had _more_ functionality than we required, IMO.
We decided to drop IRML in favor of "P" not because of limited
functionality, but because of syntax preferences.
Here I violently disagree, but it is not important for now :-).