Often, these rule engines are implemented as a rule chain. The rule chain is an ordered list of rules. Each rule consists of the following properties:
- a condition that must apply
- an action to be taken
- whether the rule chain should continue (often: always stop)
When an event enters the system, the rule chain is evaluated in order. If the condition for a rule applies, its action is performed. Depending on the design of the rule chain, the chain may stop, may continue, or may even restart. If a restart is possible, the number of restarts should be limited in order to avoid infinite loops. If no rule applies, the rule chain might have a default action.
What is an event that triggers the rule chain depends on the application. For an email client, rule chains are usually only triggered on incoming messages. Sometimes they also trigger for sent messages. It is often possible to run them manually on the inbox.
Rule chains are attractive because they are fairly cheap to run. If a rule applies, most rule chains will stop. This is also a very simple programming model. More specific rules must come first, more general rules later. This avoids complicated logic. So rule chains are an attractive way to implement some amount of customization without having to support too much flexibility. Because the set of conditions and actions is limited, rule chains can also be implemented easily with a form-based GUI, or a text-based UI.
When designing the rule engine, we can balance performance against flexibility. E.g. we can run a rule chain on every user action, but that overhead might not be worth the processing time. We can also select which conditions and actions are available, and only implement conditions if they are cheap to check.
Examples of rule chains:
Nearly all email clients have rule chains to categorize incoming messages.
Firewalls such as iptables. Because the rule chain is so limited, it can be compiled, so its fast enough to be applied to every packet in real time.
Apache web server configuration such as mod_rewrite or mod_authz_host (Deny, Allow).
The robots.txt standard actually contains two nested rulechains: first to match the user agent, then a rule chain to allow/disallow specific URLs.
Many other products such as Google Analytics or Cloudflare allow customization through rule chains. There's a whole class of automation software such as Zapier, IFTTT, or Microsoft Flow that offer comparable rule sets, but do not chain the rules.