The Kinetic Rule Language (KRL) is an ECA rule language. KRL is a programming language for creating applications on the Live Web. KRL programs, or rule sets, comprise a number of rules that respond to particular events. 

Besides a collection of rules, KRL rule sets also contain a meta section for specifying information about the rule set, a dispatch section for providing clues about event salience, and a global section for global definitions. 

Each rule conforms to the aforementioned pattern for ECA rule languages with some significant additions. The basic structure of a KRL rule is as follows:

rule <name> {
  select when <eventex>
  pre {
    <declarations>
  }
  if <expr> then
    <action>
  fired {
    <effects>
  } else {
    <effects>
  }
}

Only the name and eventex are required, so most rules are simpler than this template. (Obviously, a rule with only a name and eventex wouldn't accomplish anything, so meaningful rules include at least an action or a postlude in addition to the required components.) The prelude contains a list of variable declarations that allow computation of values for the condition and action based on global values and event attributes. Later, this chapter will discuss the KRL expression language in greater detail.

Actions specify the reaction that the rule makes to the event. Actions take two general forms:

• Actions produce directive documents that are sent to endpoints causing them to do something. For example, an email endpoint might receive a directive telling it to delete a specific message.
• Actions invoke operations in network APIs that produce some desired side effect. For example, an action might cause a Twitter update to be made to the user's status.

The section after the action is called the postlude. It allows for effects. Effects are an important addition to the ECA pattern. Effects differ from actions in that they do not result in directive documents being sent to the endpoint. Instead, they cause side effects on the KRE system. Examples of effects include the following:

• Persistent variables. An effect might cause a permanent change to a persistent variable. Persistent variables allow context to be automatically maintained for an entity or an application across separate invocations of a rule set.
• Control statements. Sometimes, you need affect the normal execution order. For example, the last statement causes the execution of the ruleset to terminate after the current rule.
• Explicit events. Explicit events allow a rule set to raise an event in response to incoming events. 
• Exception Handling and logging. Rules can raise error events that other rules respond to for handling exceptions. Also, an effect might direct the system to log something.