Configuration

It provides simple functions to access the configuration data that has been parsed using the Expat XML library from the medianode.xml configuration or from another configuration file that has been specified on the command line.

The configuration file is usually stored in the user's home directory. A configuration file in the current working directory of a started program will override the configuration file in the home directory.

The configuration file looks XML-like but it is currently not following a well-defined grammar. In spite of this, the similarity to XML and the use of classes that allow XML parsing is good for the readability and structure of the configuration even though it means programming overhead when new variables are added. Whenever new variables are added, they are meant to be listed in the descriptions that can be found by following the links on this page.

For an introduction, you may prefer to look at the Example, but for all available settings, you must follow through the individual class, start at the system level with Configuration: System

Example

A complete configuration file consists of a header and several system definitions. The following is an example definition for an arbitrary client. This is meant as an optical example, not as a working example. The configuration may not make much sense. The details of the individual flags and section can be seen below the example. The example is followed by a detailed explanation.

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE komssysconf>
<komssysconf>

<system type="client">
    <gui>
        <autostart />
    </gui>
    <rtsp>
        <destination />
        <default-server-port value="9070" />
        <no-use-proxy />
        <proxy>
            <host value="nautsterkur" />
        </proxy>
    </rtsp>
    <debug>
        <no-info-print />
        <no-warn-print />
        <error-print />
        <warn-do>
            <file value="MNRTPEncoderSH" />
        </warn-do>
        <error-dont>
            <file value="MNThread" />
        </error-dont>
    </debug>
</system>
</komssysconf>

The header <?xml ...> is currently meaningless. It would be nice to achieve well-formedness if a kind soul would fix this for us. I don't consider it relevant enough to learn the detail right now. The tag <komssysconf> introduces the actual configuration. The configuration file must contain exactly one block that is labelled <komssysconf>. Any number of configurations for one host are allowed inside this block. The individual configurations are delimited by system tags.

The single configuration in the example is defined as as <system type="client">, which determines that it is the generic client configuration. A second generic client configuration will add configuration values to the first one if different values are defined, but in case of conflicts, the resolution order is undefined.

In the system definition, variables are grouped in blocks. In the example, the blocks <gui>, <rtsp> and <debug> can be found. The <gui> is only meaningful for clients and will be ignored if found in proxies and servers. In the example case, the tag gui.autostart is set, which indicates that all GUI processes should be started together. The <autostart> is a boolean tag and it is also the default behaviour. If it appears in a configuration file like this, it is likely only present because the user of that configuration file wants to able to change this quickly to an entry <no-autostart />, which means that the default behaviour should not apply. In that case, the control front-end (the buttons or the command line) must be started separately from the decoder backend. This option exists for debugging.

The <rtsp> block is used in all system definitions and controls the RTSP behaviour of an exectable. In the example, the client is configured to send the destination token in the Transport line of an RTSP setup header, using the <destination tag. Instead of the RFC-defined port 544, the server should be expected to listen to the port 9070 for an RTSP connect, which is defined by the <default-server-port> tag. The specification of proxy usage is done in two parts to make switching between activated an de-activated proxy use easier. First the boolean tag <use-proxy> must activate the proxy use (in the example, it is de-activated instead). Second, the proxy settings must be specified. This can be the port and the hostname, but in the example, just the proxies host name is specified.

The <debug> allows the user control about the amount of debug and error messages that are printed on stdout for the running program. Komssys uses 4 debug levels: info (or debug), warn, error and fatal. Output can be blocked for all levels but fatal. Output can be enabled or disabled on a per-file basis. The example shows this. It disable both info and warn levels generally using the tags <no-info-print /> and <no-warn-print />. But for a specific file, namely MNRTPEncoderSH, this general setting has been overridden in the <warn-do> section. Similarly, error messages have been enabled generally, but they are disabled for the file MNThread specifically.

---