Hi,
Michael asked me to send the thoughts on rules and rule sets to the
mailing list for further discussion. So, here they are:
(1) As written in the draft, wildcards are essential to
specify rules.
(2) Possible actions for a rule are not only "call proxylet"
and "remote call-out", but also an action like "do NOT
do that", thus overwriting a possible wildcard rule. We
refer to such rules as "negative rules". Example: An ISP
has installed a wildcard rule that forwards all client
requests to a remote call-out server (e.g. for filtering).
Now, if one specific client keeps complaining about the
new service, the ISP might not want to shut down the
new service for all clients, but only for this specific
one => use a negative rule. Other examples include
scenarios in which you want to execute a service for all
URLs except for some specific ones (e.g. do adaptation
for all URLs except for the URLs from content providers
that threat with suing you :)
(3) If multiple rules fire on a single message, the ordering
of rules becomes very important. Example: two rules fire
on a single message, e.g. a rule for language translation
and a rule for ad insertion. In which order should the
rules fire? You might want to do the ad insertion first,
followed by the translation (or vice versa).
(4) Given that ordering of rules is important - who is
reponsible for the ordering of rules? According to the
draft, rules can be installed by different parties.
Imagine that the above mentioned rule for language
translation and for ad insertion are from different
parties. Which party defines the ordering of rules?
There might be conflicts!!! A single instance for
receiving, installing and defining the order of rules
might be a good idea (e.g. the administrator of the
proxy/cache). Of course, one might also think about
mechanisms to specify dependencies of rules..., but...
(5) My feeling is that rules should NOT be too complex.
Simple rules looking at basic message properties that
are common to most rules should be sufficient. More
enhanced "filtering" and "rule matching" should be
done in the proxylets. For example, we've implemented
a simple rule set only looking at the source address
and the destination URL of a request. If there's a match,
the associated action will be executed, for example
calling a proxylet. The proxylet itself can now do more
enhanced filtering, for example, checking the language
preferences of the user in order to determine whether
the response has to be translated.
(6) Somehow related to the above item: Message properties
to be extracted by the message parser do NOT only
depend on the protocol, but also on the rules that have
been installed. Potentially, every single line of an
HTTP header can be of interest for a rule. So, do you
want to extract all HTTP header fields in the parser?
According to (5), one could define some HTTP header
fields that are of interest to most rules, extract them
in the message parser, match rules (i.e. rules are also
restricted to these fields) and than forward the message
to a proxylet, for example. The proxylet can now further
examine the message and check the header fields that are
of specific interest. The cost, however, is more parsing
overhead...
We will keep working on our rule set implementation to see whether it
can meet the requirements of the services we have in mind. We would be
very interested in more detailed discussion, your comments, thougts,
feedback, so that we together can come up with a common and open
solution that works for all of us. Please let us know if you're
interested in that issue so that we can work together on that.
-Markus