On Mon, 28 Jun 2004, Markus Hofmann wrote:
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)?
Examples of (b) would be common actions like "strip ads for user X but
only when she is surfing with her mobile phone browser Y", or "do spam
filtering for user X unless the message is from Y"; where X and Y are
parameters. I would imagine vendors and user groups might want to
create collections of such common parameterized actions. P would need
to have something like user-defined functions to support this.
IMO, option (c) is too low-level for P, so I will not give an example.
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...
The advantage is that OPES processor will only need to support one,
albeit more complex, language instead of two or three. It is not clear
to me whether we can capture both (a) and (b) without significantly
increasing P implementation complexity.
I'm pretty reluctant to go beyond (a), which was the original intent
of the rules language.
The short definitions I provided are rather fuzzy. Please see if more
specific (b) examples above would make you a little more comfortable.
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.
I agree. This still leaves some room. For example, should P make it
easy for me to send you a piece of P code that you can use in your
proxy rules? Based on the message/action selection logic but without
the knowledge of site-specific parameters like user names or times of
restricted access.
Think about shell languages in Unix. The problem to be solved there is
which programs to execute with which parameters. Still, shell
languages differ a lot. I do not know of any shell language without
user-defined functions, but I suspect they do exist (MS command
language did not support them, right?). There are also shell languages
with sophisticated job controls. And then there is Perl that
originally was just a bit more than a shell language!
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.
I did not mean to suggest to switch back to fixing IRML. I just wanted
to support my fuzzy classification of choices with a well-understood
example.
Alex.