BIND 10 #1010: Configuration of the Python logging API

[BIND 10 Development]

#1010: Configuration of the Python logging API
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110628
                  Component:         |            Resolution:
  logging                            |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => vorner


Comment:

 Replying to [comment:5 vorner]:
 > Hello
 >
 > I noticed few things:
 >  * The distcheck fails for me, it can't find the module. For some reason
 it didn't fail before. Does it run for you?

 I've been thinking about this, and I have a new way to find the .libs dir;
 the pythonpath should already contain the correct base directory (both
 build and srcdir, in the case of tests), so it should work if we walk
 through the python path and see if isc/log/.libs is in there, and add it
 if it is. Code in commit a4f1f8de765810aecff1194c74a108682e3de28e

 >  * With the `default_logconfig_handler`, the `n` parameter doesn't seem
 too descriptive. Wouldn't there be a better name?

 Yeah it should just be module_name

 >  * The `InternalError` was kind of expected to only propagate up trough
 the stack when there already is a python exception registered. The way you
 first throw `InternalError` and after catching it, you make it
 inconsistent. Could it possibly be reversed?

 ~~Ok, done. Added a comment to the definition of InternalError to describe
 its intended use.~~

 Moot point now, see below. (did leave in the added comment)

 >  * Wouldn't the whole conversion be easier like converting to JSON
 string and passing the string to Element::fromJSON? I think the code would
 be shorter with better code reuse. But it might look less elegant on the
 other hand, so I'm not sure which one is better.

 I had thought about that, and I was not sure either. It would certainly
 save a bit of code, at the cost of two json conversions. Originally I
 chose this method because requiring JSON strings would make the interface
 slightly muddier. But now that I think about it, the JSON form is actually
 more flexible, and the actual conversion would be more or less hidden by
 the handler in the python code anyway.

 So yeah, let's do it through json. Currently simple json.dumps() calls
 suffice, so it's not that much of a change from the callers side.

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