Changes between Version 3 and Version 4 of doc/usage/doc/guides/nscp/getting_started/040

Timestamp:

08/08/11 23:09:29 (22 months ago)

Author:

gjfrater

Comment:

More changes

doc/usage/doc/guides/nscp/getting_started/040

@@ -3 +3 @@
 = 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...
+The biggest hurdle to overcome when upgrading to version 0.4.0 is the new configuration method. You can still use the "old" configuration method but it is a good idea to at least learn how the new configuration method 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 configuration in NSCP 0.4.0 has been redesigned and split 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 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:
@@ -13 +13 @@
    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.
+   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 the syntax of any changes being made.
  * 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)
+   An experimental way to load ini files over HTTP (this allows for 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.
+To specify the root or first settings store, and from there all consecutive ones, we use something that looks similar to a URL. This 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: Use the ini type provider and load the settings in 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.
+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. In the future this will be extended to provide support for loading scripts that generate configurations making 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.
+When a key is requested by a plugin or command from NSCP the root store is checked first, if the key is not found the request will be passed to the next store and then the next and so on down the line until there are no more stores to check, 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 process is the same regardless of which types of store are 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.
+Since maintaining the configuration has now been modified from the previous "edit said text file" method 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.
 
 {{{