Alex Rousskov wrote:
The two big P-questions that we may need to answer in the new
charter are:
#1. How deep does P reach? (P scope)
a) just an interface (language) for rule writer
to use when configuring/selecting existing OPES
processor actions
b) also an interface (language) for OPES processor
vendor, administrator, or 3rd party to write
generic (parameterizable) OPES processor actions
c) also an interface (language) for OPES processor
vendor or 3rd party to write protocol-specific
modules to be used when defining OPES processor
actions
Can you give practical examples of (b) and (c)?
What would be the benefits of having one language that can do all
these, as opposed to having one language for (a) and another for (b)
and/or (c)? To me, these things seem sufficiently different...
I'm pretty reluctant to go beyond (a), which was the original intent
of the rules language.
#2. How deep does our charter reach? (WG work scope)
a) just the core language (like C without the standard
library or standard template library)
b) also HTTP and SMTP module interfaces for selecting
or writing HTTP- and SMTP-related actions (like
the standard C libraries interfaces)
c) also an interface between P interpreters and
module/services suppliers? (like Unix or MS
library loading conventions)
I would consider (a) and (b) in scope.
Note that the answer to the first question determines how much work we
would have to do when documenting language core. If we limit P scope a
lot, we will have to do less work. On the other hand, if we pick wrong
scope, it may be insufficient or too complex to interest vendors in
supporting it.
The problem to be solved with the rules language is "how do I tell the
OPES processor which services have to be executed on what messages" -
a solution to that problem alone would bring us a big step forward and
would be considered valuable, I assume.
Is there a possibility to define a very simple P core while allowing,
in principle, feature-rich extensions to write P modules and such? Not
sure, but that could be the ideal approach. Kind of like Java applets
versus Java applications, but even more extreme. On the other hand, if
the core is really simple/basic, does it make sense to extend it at
all? Instead, it may be better to start from scratch for (a), (b), and
(c) in question #1 above!
I would suggest to phrase a new charter to include (1a) and (2a,b).
This does not preclude us from looking at the approach you mention
above, but it allows us to focus on the essential part in case it
turns out to be too complex.
FWIW, IRML, if further developed, would probably fit (1a) and (2b).
While I agree (and while I personally like IRML :), we made a decision
earlier to go with the "P" approach, and I would hesitate to revise
that decision without a really strong reason.
-Markus