| | 41 | == Configuration Concepts == |
| | 42 | |
| | 43 | (Again) Since the goal was to make something which is flexible enough for everyone the settings subsystem allows you to do whatever you want (almost). |
| | 44 | We currently support five main different settings stores. |
| | 45 | * old (legacy format used in 0.3.x versions) |
| | 46 | * ini New version of the ini file wich supports all new options |
| | 47 | * registry Windows registry (proper one this time) support. |
| | 48 | * http (Currently very crude way to support loading remote configuration) |
| | 49 | * dummy In-memory store which cannot be saved. (mainly used for scripts and such which will create a temporary run which does not require saving) |
| | 50 | |
| | 51 | The "cool" thing about the whole concept is that on store can include another this means that if I want to keep my legacy "old" store I can simply create a include section which includes a ini file and thus have another file where I can place all new configuration settings. Or if I want to have the bulk of the config in the registry but allow an administrator the ability to override some keys locally we can (from the registry) include a file and vice verse. |
| | 52 | |
| | 53 | The actual settings are key value pairs store in a hierarchical tree (much like the registry in that regards logical grouping). But of course we can still store this in a file thus the end result is: |
| | 54 | {{{ |
| | 55 | [/settings/NSCA/client/targets/default] |
| | 56 | host=192.168.0.1 |
| | 57 | encryption=aes |
| | 58 | }}} |
| | 59 | |
| | 60 | Where you can notice the '''/settings/NSCA/client/targets/default''' which is the hierarchical path '''host''' is the key and '''192.168.0.1''' is the value. |
| | 61 | |
| | 62 | For more details about configuration see the configuration section [[wiki:doc/configuration/0.4.x]]. |
| | 63 | |