Syntax

Syntax

The syntax of the driplane’s rules is very simple. As for the BASH every filter’s output is sent to the next filter’s input concatenating the two of them with the | character.
All the rules have to start with a name and end with a ; char.

Import

Using the directive import it is possible to include one or more files and their rules in another one. All the rules defined in an included file
are available for the file that imports them.

To use this directive the path of the file can be absolute or relative to the rules directory specified in the configuration:

Example:
#import "file_to_import.rule"

Rule Name and Rule Call

Each rule has to start with an identifier follow by =>. This identifier identifies rule name and it could be used in another rule to concatenate 2 rules together.

This name must be unique in the rules.

Example:
IDENTIFIER => ... ;

It can be included in another rule (rule call) prepending the @ to it.

Example:
IDENTIFIER1 => ... ;
IDENTIFIER2 => ... | @IDENTIFIER1 | ... ;

Feeder

The feeder creates the stream, so they don’t accept inputs. For this reason, they can be positioned ONLY to the beginning of a rule.

The feeder definition starts with a < char followed by an identifier. That’s the type of the feeder we want to use.

After the type we found a : char followed by a list of parameters comma separated and a >.

The parameters are in the form of key/value where the value is between double quotes key="value".

Example:
IDENTIFIER => <FEEDER_TYPE: param1="value1", param2="value2"> | ... ;

Filter

The filters are the main operators of a rule, because they decide if a data is interesting and perform operations.

The definition of a filter start with his name and it is followed by parameters contained between ( and ).
According to the settings a Filter can change his behaviour and can modify the data passing through it.

Example:
IDENTIFIER => ... | FILTER_TYPE( param1="value1", ... ) | ... ;

The operator NOT ! can be used on filter to negate his result (propagate the data if the condition is not verified).
It has to be put before the filter definition: !FILTER_TYPE(...)
All the parameters have to be enclosed in quotes.
JSON requires double quotes to encode strings, so in order to define a JSON string you need to escape the quotes \".

Data message and Extra

The data stream in driplane is based on text and the basic object that is part of it is the Message.
The Message is an object that contains the text that needs to be filtered and extra.
The main string is identified as text in the filters, whereas the extra data are identified by a key.

There are fixed extra, created from driplane itself and other extras related to a feeder or filter.

NameDescription
source_feederthe name of the feeder creates this Message
rule_namethe name of the rule that contains this filter