1. zaccone
  2. quechua


Clone wiki

quechua / Configuration


Almost all the options in Quechua are configured by configuration file. We will walk through the config file, and its' sections and explain them one by one. You will soon notice that the general principles are identical in every section and adding new components and configuring them is very easy. When in doubt you can always check its' docs.

The sections

Quechua's configuration file is divided into few main sections and we will depict them one by one.

  1. quechua version 0.1
version = "0.1";

You must specify version of the configuration file. If the version is not compatible with the one Quechua expects, the error will be printed and the application will exit.

quechua: {

Everything (except version directive) should be wrapper with quechua section.

    libraries: {
        load = ["stdch","stubproc","filelogger","reverter","stubalg","dnchan","ipproc","postprocessortest","apriori"];
        files= {stdch = "stdch.so";
                filelogger = "stdch.so";

This section defines what libraries should be loaded (in load subsection) and in what files (.so files) those librarie are stored the files subsection). The .so files are stored in $QUECHUA/libs/quechua/. Only modules from load subsection will be loaded. In every shared library (.so file) you can store many components but not of the same type (that is, you cannot store multiple Channels in stdch.so shared library).

    channels: {
        load = ["stdch","dnchan"];
        stdch: {
            param1 = "p1";
            param2 = "p2";
            param3 = "p3";
        dnchan: {

Since channels are standalone (they are not initialized nor handled by workflows or other components) the deserve their own sections. Here, again you specify what channels should be loaded and write channel-specific parameters.

Important In the load subsection you can only put names of the modules loaded in the libraries subsection. Quechua will then try loading Channel from the library.

In this example, dnchan channel will use credentials from the channel-specific parameters to connect the database.

    loggers: {
        load = ["postprocessortest","filelogger"];
        filelogger: {

        postprocessortest: {
            interval="1D"; # 1 day


The story with Loggers section is the same as with Channels. No reason to repeat myself.

    flows: {
        load = ["f2"];
        f1: {
            channel = "stdch"; // must be channel's name
            processor: {
                name = "stubproc";
                depth = 4; # stupid example
                ip    = 46;  # stupid example
            algorithm: {
                name ="stubalg";
                prefix="STUBALG: ";
            logger = "filelogger";

            type = "triggered";

        f2: {
            channel = "dnchan"; // must be channel's name
            processor: {
                name = "ipproc";
            algorithm: {
            logger = "postprocessortest";

            type = "triggered"; 

Flows, or rather workflows are the last section to be configured. They are, however, the most advanced (if this the right word in here) section. All the workflows are stored in flows section.

Just like before, you load flows you want, andconfigure them the way you want to.

Every flow subsection defines:

Channel the flow registers to, Logger the flow uses to log its output, Processor the flow uses, Algorithm the flow uses, Running mode (type directive)

Important You may omit every component, i.e if you skip Processor the data from the Channel will go straight to the Algorithm instance. This is fine, if you are sure it will work. On the other hand, if you skip Channel no data will be ever received, and if you skip Logger the resulted data will be discarded, and nothing will be logged.

Important Keep in mind, that Processors and Algorithms are instantiated per Workflow. This means, that if you use stdch in workflows f1 and f2 two stdch instances will be created and used.

}; # quechua section

End of the main section, simple :-)