BIND 10 #736: Implement logging configuration

[BIND 10 Development]

#736: Implement logging configuration
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110614
                   Priority:         |            Resolution:
  critical                           |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  logging                            |  Estimated Difficulty:  7.0
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => jelte


Comment:

 All OK, please merge.

 >> Comment: again not in the changes here, but some of the functions in
 the file are either in the anonymous namespace or are declared static.
 This means they do not have unit tests.
 > Yep. It also means we won't accidentally be using them outside of this
 scope, which, if i look at your previous comments, may be a very good
 thing :) They are so extremely specific to the one function that calls
 them, I honestly don't know how much value they would be for other parts.
 I do realize that this is not very TDD, but:
 One scheme I have tried is to put these type of functions as static
 protected methods of the class. In the unit tests, declare a derived class
 and add public methods that do nothing more than call the superclass's
 protected methods.  This protects them against accidental use (except for
 derived classes, and we have to assume that the person deriving the class
 knows what they're doing) but makes them available for testing.

 > On a more general note, I think we are running against the limits of
 using 'direct' data types for both config values and their specifications
 (the ElementPtrs? in c++ and the native types in python).
 Would the class boost::variant be of use here?

-- 
Ticket URL: <http://bind10.isc.org/ticket/736#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development