|
KISSCPP
a C++ library for rapid application development
|
|
KISSCPP
a C++ library for rapid application development
|
Your KISSCPP derived applications, will be implementing handlers of it's own. But there are certain things that all applications need. Here is a short list of some of those things:
KISSCPP aims to provide standardised mechanisms for all of the above, and more.
Here is a list of the standard handlers, currently implemented by KISSCPP.
The kch prefix, is shorthand for (K)iss(C)pp (H)andler. To prevent conflict between KISSCPP specific handlers and your own, do not prefix any of your custom handler identifiers with kch.
| Handler Id | Purpose |
|---|---|
| kch-loglevel | Adjust the logging to specified levels |
| kch-handlers | shows a list of the request handlers for this application |
| kch-errstat | retrieves the application error states |
| kch-errclear | Used to marks an application error state as cleared. |
| kch-stat | retrieves the application statistics |
In order to ease the introduction to this here, we'll start with discussing the adjustment of log levels.
For a discussion on what log levels are and how they are used, please see the section on logging.
| Handler | Purpose |
|---|---|
| kch-loglevel | Used to set the logging level to new values, while an application is running. |
| Parameter name | Mandatory? | possible values |
|---|---|---|
| type | Yes | "debug", "info", "error" |
| severity | Yes | "low", "normal", "high" |
Here is an example of a bash script one can use for setting an application's log levels from the command line.
Logging and it's implementation in KISSCPP is discussed here.
This is a discussion on how to change the type and severity of logs that are written by an application, while the application is running.
The standard handler for this is called
After much investigation and debate, JSON was yet again selected as the preferred format. In the case of configuration files, we found that INI format lacks the ability for nested records and XML quickly becomes an unreadable mess. The only down side we have identified with the use of JSON as a configuration file format, was it's lack of native support for comments. This is a shortcoming we are more than willing to live with.
The following are reserved identifiers, for use in configuration files: Note: The prefix of kcc is shorthand for (K)iss(C)pp (C)onfiguration.
The kcc prefix, is shorthand for (K)iss(C)pp (C)onfiguration. To prevent conflict between KISSCPP specific configuration and your own application data, do not prefix any of your custom configuration variables with kcc.
| Identifier | Description |
|---|---|
| kcc-server.address | the hostname or ip address of the server. |
| kcc-server.port | the port of the server. |
| kcc-stats.gather-period | Seconds between gathering statistics for historic purposes. |
| kcc-stats.history-length | Number of historic stats gatherings to keep. |
| kcc-log-level.type | The default type limitation on logs. |
| kcc-log-level.severity | The default severity limitation on logs. |
| kcc-white-list | A root node containing data regarding white list communications. More detail available here. |
KISSCPP applications will have configuration files named as follows:
i.e. An application with the id "foo", being executed with an instance identifier of "bar" will look for a configuration file named:
This file must contain configuration data that is specific to the foo application running as instance bar.
There is however, a mechanism for allowing shared configuration to exist in a single file. This is known as the common-configuration file. This file will have the instance id portion of the file name, replaced by the string "common".
i.e. An application with the id foo, being executed with an instance identifier of bar will look for shared configuration details in a file named.
Due to the fact that KISSCPP is a library meant for large systems consisting of interdependent processes, we did have to standardize on most aspects of the configuration files. The control we can give you, is based around a holistic approach, and the fact that the developer is not the only one that needs to be considered here. System administrators and support personnel also need to have a sane standard to work with.
As such, the following decision were made:
The configuration file path, is constructed in one of three ways:
That means, when you have a KISSCPP application with the name foo and you start instance bar of it, while having KCPP_CFG_ROOT set to /put/configurations/here
Your application will look in:
Meaning that the full path to these files will be:
Now, with all of that in play, you can still set the KCPP_EXEC_ENV environment variable. This comes in handy when you have differing configurations for your test, quality control and production environments.
Thus, with all the above and KCPP_EXEC_ENV set too: live
Your application will look in:
Meaning that the full path to these files will be:
Ok, let's say you have an application called ninjarules and you need to run three instances of that application on the same machine.
To keep things sane, you set KCPP_CFG_ROOT too /my/central/config. You also know that your test and your live environments will have different configurations so you plan on setting KCPP_EXEC_ENV to live and test respectively, so that you can avoid having to maintain both sets of configurations in one file.
You further decide, although you can use any arbitrary string as an instance identifier, that you'll stick to the simple numbers 1, 2 and 3, for your various instances.
Your application will therefore look in these directories:
For files named:
There are some things that will be common for all instances of ninjarules, so you'll want to keep them in the common configuration. Here's an example of that:
And then of course, there will be the instance level configuration files:
1.8.6
