We've had some changes in the Kynetx platform, KNS, over the last few weeks that I wanted to update people on.

First, a few weeks ago, we cut over to a new parser. Yeah, if you're keeping score, this is number 3. The first parser was based on HOP. We replaced that with Damian Conway's Parse::RecDescent as chronicled in a blog post I did in September of 2008. The third (last?) parser is based on the ANTLR parser generator. Cid Dennis did most of the hard work of creating the new Parser and Mark Horstmeier did the Perl integration using Inline::Java.

We switched for speed. The old parser was starting to choke on large rulesets. Other than a syntax change forced upon us by losing the flexibility of doing lexing and parsing at the same time, the new parser was deployed without any significant problems due to the large suite of tests we created the last time we did this. I don't like ANTLR's input file as much as RecDescent and the fact that it creates Java means we have to jump through some hoops to make it work in our system, but it's several orders of magnitude faster than the old parser. I'm confident the new parser will take us a long way and don't anticipate a changeout.

I wrote about explicit events a few weeks ago. These are proving to be a very powerful addition to the language. As originally written, event names and target rulesets were denoted by name. As I mentioned, we've fixed that by allowing these to both be denoted by expressions. This makes explicit events much more powerful.

We found a similar limitation where we'd required that the keys in a literal hash be strings. This was limiting how developers used them so we relaxed that as well and now the key in a literal hash can be any expression--as long as it evaluates to a string or number.

As I wrote in KRL Patterns: Building Event Intermediaries, often rules that are acting on events don't need actions to be useful. The postlude becomes the rule focus because that's where events are raised. In order to accomodate this pattern without requiring developer to include the "noop" action, we've made actions optional.

Finally, I recently checked-in code to make the rule mode optional. If you're not familiar with rule modes, that's because it's a string you probably just mindlessly cut and paste in your rulesets without really knowing what is does. In the following example rule, the "is active" is the rule's mode:

rule example_1 is active {
  select when pageview ".*"
  ...
}

You can say "is inactive" and the rule will cease to fire without commenting out the entire rule. You can also say "is test" if you're working with an endpoint that can be put in test mode. In test mode, all active and test rules fire. Most rules, however, are active so in a nod to convention over configuration, we've made the rule mode optional, so the previous example can be written:

rule example_2 {
  select when pageview ".*"
  ...
}

With all these optional parts, the simplest rule possible is now:

rule example_3 {
  select when pageview ".*"
}

The only required components of a rule are the name and the event expression. Of course, this rule doesn't do anything, but that's a different matter.

In addition to these, we've also made less visible changes to KNS to make the platform perform as expected (i.e. we fixed a few bugs) and layed the groundwork for some significant changes coming soon. Stay tuned!