Subject: Re: draft-beck-opes-irml-03.txt

From: Markus Hofmann <[email-masked]>
Date: Thu, 24 Jul 2003 16:45:02 -0400

Folks,

we need to get going on the rules language as well, we're already late 
on this one!

There was only a single email from Alex coming back as response to the 
re-submitted IRML draft (draft-beck-opes-irml-03.txt). The intent has 
been to stimulate some discussions around this topic and to get 
started working on it...

Well, if there's nothing more to discuss and no one is coming up with 
modifications or alternatives to the approach presented in the IRML 
draft, maybe we should move forward with it and declare it a WG draft. 
If not, please engage on this mailing list and provide alternative 
thoughts and approaches.

We're aiming to submit an initial WG document on the rules language in 
August!

Thanks,
   Markus

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 24 Jul 2003 15:02:07 -0600

The rules language should not be a programming language - it should be
a constrained language that can be compiled into efficient runtime
dispatches.  XML seems like a reasonable way to represent rules,
prior to compilation.  

The elements needed are regular expressions based on tokens; the
tokens should encompass not only character strings but also
grammatical elements from the underlying protocol.  A BNF definition
of the underlying protocol, for example, should provide the basis
for the OPES rules language to specify header and body constructs.

However, I believe that the constraint of triggering only a single
action is too severe.  It is important to be able to specify
sequencing: e.g., action1, then action2.

I am a proponent of an approach that supports detailed parsing of
cached content.  In this model, the OPES processor would take the
content-related rule elements and compile them into a single parsing
routine.  This code might run on an OPES helper machine.  The OPES
processor would then attach the parsed attributes to cached items.
Requests for such items would trigger OPES rules related to requestor
profiles; the rules would determine which OPES services were to be
applied to the cached items (such as, delivering an already modified and
cached item, or applying further customization to such an item, or blocking
the item).

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 24 Jul 2003 15:58:00 -0600 (MDT)

On Thu, 24 Jul 2003, Markus Hofmann wrote:

> we need to get going on the rules language as well, we're already
> late on this one!

I will respond to questions raised by my e-mail. For now, I am _not_
arguing that the rule language should be a general purpose programming
language. I am arguing that it should be a domain specific language
that allows for powerful and simple expression of what rules need to
express. Or, at least, we should seriously consider that option.

I will try to show that XML presents virtually no advantages compared
to a domain specific language and introduces significant hurdles.

I am on travel and may not be able to comment on this promptly,
unfortunately.

N.B. It is theoretically possible to continue working on the language
without agreeing on its representation (XML or custom).

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 25 Jul 2003 09:28:30 -0400

The Purple Streak, Hilarie Orman wrote:

> The elements needed are regular expressions based on tokens;

While it would be very helpful to have regular expressions, parsing 
rules and handling of rules with regular expressions can be quite 
expensive wrt processing capacity required - an OPES processor with a 
large number of such rules could easily become a bottleneck...

It's a tradeoff between flexibility and performance.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 25 Jul 2003 09:32:31 -0400

> to a domain specific language and introduces significant hurdles.

I assume "domain specific language" implies a "custom/new/specific" 
language?

If so, allow me to raise flag in that we should use existing 
approaches (e.g. XML or others) as long as they don't have serious 
disadvantages, rather than inventing everything ourselves.

We're working with the goal of having an initial WG document in August 
time frame...

-Markus

---

From: Andre Beck <[email-masked]>
Date: Fri, 25 Jul 2003 10:54:38 -0400

Hilarie,

> dispatches.  XML seems like a reasonable way to represent rules,

I agree.

> sequencing: e.g., action1, then action2.

I agree again. IRML already supports just that: it lets you specify one
or more OPES services that are to be executed in the specified order.
However, there still has to be a policy that determines how to order
service execution requests from different rule authors.

> cached item, or applying further customization to such an item, or blocking

Would this be a performance optimization for those requests that can be
served from cache? In other words, are you proposing to cache not only
the content but also some aspects of the rule processing results for
that content?

Andre

---

From: jfcm <[email-masked]>
Date: Fri, 25 Jul 2003 17:25:30 +0200

At 23:58 24/07/03, Alex Rousskov wrote:
>I will try to show that XML presents virtually no advantages compared to a 
>domain specific language and introduces significant hurdles.

Total agreement.
jfc

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 25 Jul 2003 11:02:20 -0600

Once compiled, the rules can be executed with great efficiency.
There are a couple of forms that must be excluded, but the statement
that the processor would "easily" become a bottleneck is not
true.

Hilarie

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 25 Jul 2003 11:22:44 -0600

>  service execution requests from different rule authors.

Or even from the same author?  There are many possible policies, but
it might be good enough to say to order them by two metrics: most
specific pre-condition match and specific ordering.  Rules can have
ordering metrics of "always first" "always last" "first of equal
specificity", "last of equal specificity".  

>  the content but also some aspects of the rule processing results for

I'm planning on caching results of doing checks of the precondition
clauses.  For example, if a precondition is 

http:originatingsite =~*.troubletrouble.com

then the cached content may get a tag of
"precondition3881" entered into its "directory" entry (the 3881 is an
arbitrary number assigned to the precondition, thus making the
precondition into a boolean variable).

Hilarie