BIND 10 trac3113_test, updated. d21b3e92d6825acb41512747991b94f145d66199 [3113_test] Minor updates to the documentation

[BIND 10 source code commits]

The branch, trac3113_test has been updated
       via  d21b3e92d6825acb41512747991b94f145d66199 (commit)
      from  9e3e043fd5b34eaf866bd590fae3a3a252ac2bff (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit d21b3e92d6825acb41512747991b94f145d66199
Author: Stephen Morris <stephen at isc.org>
Date:   Mon Sep 9 18:45:07 2013 +0100

    [3113_test] Minor updates to the documentation

-----------------------------------------------------------------------

Summary of changes:
 src/lib/hooks/hooks_maintenance.dox |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

-----------------------------------------------------------------------
diff --git a/src/lib/hooks/hooks_maintenance.dox b/src/lib/hooks/hooks_maintenance.dox
index aa933f0..51a07dc 100644
--- a/src/lib/hooks/hooks_maintenance.dox
+++ b/src/lib/hooks/hooks_maintenance.dox
@@ -317,17 +317,17 @@
 
  Within the code users by the user's hooks library, the ServerHooks
  object is used by @ref isc::hooks::CalloutHandle and @ref
- isc::hooks::CalloutManager objects.  Both of these objects are
- passed to the hooks library code when a callout is called: the former
- directly through the callout argument list, the latter indirectly
- as a pointer to it is stored in the CalloutHandle.  This allows
- a solution to the problem: instead of accessing the singleton via
- ServerHooks::getServerHooks(), the constructors of these objects store
- a reference to the singleton ServerHooks when they are created and use
- that reference to access ServerHooks data.  Since both CalloutHandle
- and CalloutManager are created in the statically-linked BIND 10 server,
- use of the reference means that it is the singleton within the server -
- and not the one within the user's hooks library - that is referenced.
+ isc::hooks::CalloutManager objects.  Both these objects are passed to the
+ hooks library code when a callout is called: the former directly through
+ the callout argument list, the latter indirectly as a pointer to it is
+ stored in the CalloutHandle.  This allows a solution to the problem:
+ instead of accessing the singleton via ServerHooks::getServerHooks(),
+ the constructors of these objects store a reference to the singleton
+ ServerHooks when they are created and use that reference to access
+ ServerHooks data.  Since both CalloutHandle and CalloutManager are
+ created in the statically-linked BIND 10 server, use of the reference
+ means that it is the singleton within the server - and not the one
+ within the user's hooks library - that is referenced.
 
  The solution of the logging problem is not so straightforward.  Within
  BIND 10, there are two logging components, the BIND 10 logging framework
@@ -350,8 +350,8 @@
  global variables is performed once.
 
  The next two tasks - static initialization of the messages in the BIND
- 10 libraries and the static initialization of the logging framework
- - is performed twice, once in the context of the BIND 10 server and
+ 10 libraries and the static initialization of the logging framework -
+ are performed twice, once in the context of the BIND 10 server and
  once in the context of the hooks library.  For this reason, run-time
  initialization of the logging framework needs to be performed twice,
  once in the context of the BIND 10 server and once in the context of the