| Version 3 (modified by gjfrater, 22 months ago) (diff) |
|---|
TracNav
0.4.0: Getting started
The biggest hurdle to overcome when it comes to the step up to version 0.4.0 is the new configuration method. You can still use the "old" configuration method but it is probably a good idea to learn how the new configuration works and how to incorporate it with the old method. The "new" and the "old" methods are not mutually exclusive, but before we get started on that lets go through some theory...
Configuration
The configuration in NSCP 0.4.0 has been redesigned and extracted into separate modules (albeit still inside the same physical executable). The idea is that a "settings store" is loaded which can be implemented using one or more of several different configuration providers. This "store" can then in turn include other types (using different providers). So from the "old" configuration you can include the "new" and vice versa.
The current list of providers are:
- ini A plain text file in the form of an ini file that uses an extended "path like" syntax in the section headers (foo/bar as opposed to [foo bar]).
- registry Tree structure stored inside the registry. This has the drawback of not having any comments and/or descriptions available which means you need to know what your wanting to do before hand.
- old The "old" text file format, in reality this is a text file mapping of "old" keys into the corresponding "new" ones
- http An experimental way to load ini files over HTTP (this provides remote configurations)
To specify the root or first settings store, and for that matter all consecutive ones, we use something which looks similar to a URL. The URL has a set of properties which are expanded when the file is loaded, for example ini://${exe-path}/nsclient.ini will be read like as: Use the ini provider and load the file nsclient.ini which resides in the same folder as the NSCP executable. There is also a shorthand "ini" which will be the same.
All providers have support for "including" other stores from different providers (http, old method, etc.) thus you can start with an old file store and include an ini file and/or a http file and so on. The goal is to extend this idea in the future to provide support for loading scripts that generate configurations which will make this even more flexible.
When a key is requested by a plugin or command from NSCP the root store will be checked first and then if the key is not found the request will be passed to the next store down the line until either there are no more settings stores, if the key is still not found it will be marked as "not found" which in most cases will result in a default value being used. This is the same regardless of which type of store is used. The "search" is recursive, meaning if A includes B and C and B in turn includes D D will be searched before C.
Using the configuration from command line
Since maintaining the configuration has now been abstracted from the previous "edit said text file" there is a whole set of new commands to manipulate the settings store and the various aspects surrounding it. The best way to understand how it works is to start NSCP with the command line option --settings-help which gives you a list of all available command line arguments and a short description of what they do.
>nscp --settings-help
Settings options:
--migrate-to arg Migrate (copy) settings from current store to target
store
--migrate-from arg Migrate (copy) settings from current store to target
store
--generate arg (re)Generate a commented settings store or similar KEY
can be trac, settings or the target store.
--add-defaults Add all default (if missing) values.
--path arg Path of key to work with.
--key arg Key to work with.
--set arg Set a key and path to a given value.
--show Set a value given a key and path.
--list Set all keys below the path (or root).
This tells us we can do: nscp --settings --list to get a list of all keys in all used settings store in other words what the program will see. Another quite handy command is:
nscp --settings --migrate-to ini
Which will take (if you are using the old file) your old settings file and convert it to the new ini format as well as update the boot.ini to use the new settings store.
To make this even more useful we can add --add-defaults which will add all available keys and their default values (in effect generating a nice new nsclient.ini file for us) like so:
nscp --settings --migrate-to ini --add-defaults
There is also commands to set values --settings --path /foo --key bar --set test as well as generate a file from scratch (or update the current one) nscp --settings --generate ini --add-defaults.
That is all for now but perhaps I will extend this a bit later on.








