BIND 10 #1253: Datasource refactor finishing touch 3: factory/containers and wrappers

[BIND 10 Development]

#1253: Datasource refactor finishing touch 3: factory/containers and wrappers
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  UnAssigned
                       Type:  task   |                Status:  reviewing
                   Priority:  minor  |             Milestone:
                  Component:  data   |  Sprint-20111011
  source                             |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:         |  Estimated Difficulty:  3
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => UnAssigned
 * status:  assigned => reviewing


Comment:

 Ready for review.

 Instead of wrapping the factory classes themselves, I decided to simply
 make the python isc.datasrc.Client class wrap the DataSourceContainer
 instead of the DataSource directly. It then calls the needed functions on
 the contained datasource instance instead of through a separate python
 class.

 Most of the changes however are other issues this change revealed;
 - I added an optional parameter to various createXXX() functions; it now
 takes a PyObject*, and if not NULL, it'll INCREF the object, and DECREF it
 upon destruction. This way we can make sure any object that the object
 created by createXXX needs to be alive during its lifetime will be. (in
 this case we need Client not to be destroyed before ZoneIterator,
 ZoneUpdater, or ZoneFinder are)
 - I've added a few catches in factory.cc's create() call; they simply copy
 the exception and reraise it. There is a problem if we don't do so, if the
 creation fails because of one of those exceptions, the loaded library may
 be unloaded, and the stack unroll loop may then want to look into it to
 see what the exception is. By copying it outside of the dynlib we should
 be able to avoid this problem. This may mean we need to strictly define
 which exceptions can be raised (or maybe i'm just overseeing something
 here).

 Oh and one additional comment; i've made the datasource config parameter
 of the lowest-common-denominator type; i.e. a string containing a JSON
 representation. We may want to add more advanced types in the future but
 this should be usable enough for the near future.

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