Alex Rousskov wrote:
I may have few friends left after this message, but I hope that these
comments would do at least some good as well.
Don't worry, Alex. We appreciate any and all (constructive) comments...
0) IRLM draft provides insufficient set of general mechanisms for rule
specification yet also documents many HTTP-specific extensions or
bindings. This must be fixed. The draft should either define core
mechanisms and strive to be application agnostic or be
HTTP-specific. In either case, major additions and changes would be
required: more general mechanisms are needed and more/different
HTTP-specific bindings are required. In other words, I am not just
talking about splitting the draft in two.
I absolutely agree that the goal should be to have a protocol-agnostic
rule matching core and protocol-specific extensions. Earlier versions of
IRML were HTTP-specific and since then we have tried to separate the
HTTP-specific parts from the generic parts, but, as you pointed out,
more work needs to be done to complete this process.
1) IRLM is closely tied to a very narrow interpretation of the OPES
architecture. The language should focus on a more general (yet
well-scoped) task of expressing a message adaptation rule:
if "condition" then do "action";
The "condition" expression should be powerful enough to express a
mixture of processing points, processor state, application message
properties, and extensions. The draft artificially segregates, for
example, processing points, from message properties, severely
limiting expression power.
The "property" element can already refer to application message
properties (i.e. protocol header values), environment/system variables,
and sub-system properties. I don't consider the processing point a rule
condition. Rather, I believe it's a rule attribute as it specifies when
a rule is to be processed. As such, I don't see how the current IRML
design limits expression power. Can you think of a specific example that
shows where IRML lacks expression power?
2) IRML attempts to enforce rules authorship. IMO, the Rule
Specification language must focus on specifying the rules, not
trying to specify or enforce who has the right to submit or execute
them. For example, imagine C or Java languages with constructs to
specify/enforce software copyright. I believe that rights
specification and enforcement requires different mechanisms from
rules specification. Moreover, both mechanisms lack key features in
the current draft.
I am not sure IRML attempts to enforce rule authorship/authorization. It
does allow rule authors to specify rule authorship/authorization, but
how this is enforced is up to the OPES processor or whatever OPES
element receives IRML rules. Generally, I agree with your statement,
though.
3) I doubt that efficient rule processing would be possible with IRML.
The language provides no mechanisms to reuse groups of rules (e.g.,
procedures or functions) or to reuse computation results (i.e.,
variables). Without such mechanisms, a realistic IRML program will
be slow. It will also be huge and difficult to manage.
Well, we never envisioned that an OPES processor would actually process
IRML rule files on the fly as it receives user requests/responses.
Instead, we figured that there would be a separate offline process that
receives IRML rule files from external sources, validates them and
subsequently translates them into some internal, proprietary format
optimized for efficient rule processing.
4) I question the choice of XML syntax. Rule specification is much
closer to a program than it is to a static tree of configuration
options. I believe that the history of languages used to express
application routing, load balancing, and filtering decisions at
intermediaries proves my point: while the industry has started with
simple maps and tables, the application-level requirements forced
implementors to support much more flexible rule programming. The
choice of XML as IRLM syntax makes it very awkward to express
anything that goes beyond a simple rule. IMO, XML must not be used
as a programming language syntax.
I don't think it's realistic to expect that OPES processors would be
able to process whatever you can express with a full-fledged programming
language just to determine which requests/responses need further OPES
processing. This would probably impose an unacceptable performance
penalty on those transactions that don't need further processing. Also,
I doubt that a service provider would let external rule authors specify
complex rule logic that could use up any amount of processing power,
e.g. through loops etc. For these reasons we decided to keep IRML rules
very simple and XML seems to be a very suitable format to do just that.
XML justification in the draft is "many publicly available parsers
and editing tools can be used". This is a very weak argument
because (a) getting XML tree parsed is only a minor step towards
interpreting IRML and
True, but would this second step by any easier if we used a different
format?
(b) there are more XML-unaware editing tools
than XML-aware editing tools.
True, but then again non-XML formats would have the same problem, right?
Thanks,
Andre