[svn] commit: r1042 - /trunk/src/lib/config/documentation.txt

[BIND 10 source code commits]

Author: jelte
Date: Sun Feb 28 20:54:40 2010
New Revision: 1042

Log:
update documentation.txt to the changes i just made (that only changes configuration items are passed to the given comnfig handler)

Modified:
    trunk/src/lib/config/documentation.txt

Modified: trunk/src/lib/config/documentation.txt
==============================================================================
--- trunk/src/lib/config/documentation.txt (original)
+++ trunk/src/lib/config/documentation.txt Sun Feb 28 20:54:40 2010
@@ -30,11 +30,9 @@
 
 If it doesn't validate, an error is sent back to the manager, and subsequently to the UI (though this is not implemented yet).
 
-If it does, a callback function specified by the module itself is called, with the new non-default configuration values.
+If it does, a callback function specified by the module itself is called, with the a MapElement containing the configuration items that have changed.
 
-We are planning to do a sort of diff-like thing here, but the current version only handles full non-default configuration values.
-
-The callback function returns a messge containing either success or failure, and on success, the new configuration is locally stored in the modules session. Plans are to make this optional, so that modules have two choices; they can have the configuration stored for random access later, or they can run through the configuration when there is a changes, modify their internal structures, and then drop the full configuration. This makes handling configuration updates more complicated, but is more efficient assuming that configuration values are much more often read than written.
+The callback function returns a message containing either success or failure, and on success, the new configuration is locally stored in the modules session. Plans are to make this optional, so that modules have two choices; they can have the configuration stored for random access later, or they can run through the configuration when there is a changes, modify their internal structures, and then drop the full configuration. This makes handling configuration updates more complicated, but is more efficient assuming that configuration values are much more often read than written.
 
 Commands are handled in a similar way, but do not go through the configuration manager.
 
@@ -53,9 +51,9 @@
 isc::data::ElementPtr my_config_handler(isc::data::ElementPtr new_config);
 [link to Element doxygen html]
 
-The new_config is a ElementPtr pointing to a MapElement containing data in the form as specified by the specification file. It only contains non-default values, though that includes values that are set by the administrator which happens to be the same as the default).
+The new_config is a ElementPtr pointing to a MapElement containing data in the form as specified by the specification file. It only contains values that were changed.
 
-The module can walk through this set and alter it's behaviour accordingly if necessary. It can also simply return success (see below) and reference the needed configuration values directly when necessary by calling get_config_value(std::string identifier).
+The module can walk through this set and alter it's behaviour accordingly if necessary. It can also simply check them and return success (see below) and reference the needed configuration values directly when necessary by calling get_config_value(std::string identifier).
 
 The callback function must return an answer message, which is created with isc::config::createAnswer(). For successful handling of the configuration, it should return the result of createAnswer(0) (0 being the result code for success). If there is a problem, the function can return the result of createAnswer(non-zero, "string_with_error_message"). In this case, the new configuration is not stored, and the error is fed back to the configuration manager.