BIND 10 #2853: Python wrapper of data source extensions

[BIND 10 Development]

#2853: Python wrapper of data source extensions
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130625
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => vorner


Comment:

 Hi Michal

 Replying to [comment:27 vorner]:
 > Hello
 >
 > I seem to be getting confused around too many responses to too many
 > things. What is the motivation for splitting the constructor? Is it
 > something outside of this ticket? Or reaction to some of the comments
 > here?

 `getStatus()` needed to be corrected, so that the Python unittests could
 be tested properly. When fixing `getStatus()`, it was observed that a
 caller which constructs `DataSourceStatus` objects cannot pass any valid
 value for `type` argument when the segment state was
 `SEGMENT_UNUSED`. The correct way to address this is by hiding any
 implementation representation inside `DataSourceStatus` and letting the
 caller not pass the `type` argument when state is `SEGMENT_UNUSED`.

 > With the documentation, well, there must be some point where the C++
 > object is taken and wrapped into python. And, in this point, it must
 > be created by some C++ code that is wrapped into a python
 > function/method. The parameter must be passed to the created object
 > _somewhere_ and as the calling application is python one, it must be
 > some python wrapper that calls the C++ routines to create it.
 >
 > So, which point in the wrappers is it? Is it one point or many? Is the
 > value of the parameter hardcoded in the python wrappers, or can it be
 > specified by some parameter of python wrapper somewhere?
 >
 > It is not possible to the object to come to existence out of thin air.

 Let me explain what is happening so you understand clearly. Then I'll do
 what you tell me to, because I don't have a good idea what is more
 "correct".

 There is a Python `ZoneWriter` object that wraps a C++ `ZoneWriter`
 object. Its behavior is based on how the C++ `ZoneWriter` object was
 constructed. It is not possible for Python code to directly construct
 `ZoneWriter` objects, but they can get a pre-constructed Python
 `ZoneWriter` object as a return value from some methods.

 In the Python bindings code, we only have one place returning such an
 object now, which is the `get_cached_zone_writer()` Python method (see
 `ConfigurableClientList_getCachedZoneWriter()`). Even this code does not
 directly construct a C++ `ZoneWriter`, but uses what is returned by C++
 `ConfigurableClientList::getCachedZoneWriter()` and wraps a Python
 object around it. The arguments that are used to construct this
 C++ `ZoneWriter` are well inside the C++ datasrc library.

 The point here is this: We are documenting the `ZoneWriter` Python
 class. If in Python code, you have a `ZoneWriter` object, it does not
 know where the object came from. It could have come from
 `get_cached_zone_writer()` or some other method.  But the Python
 documentation has to describe its behavior regardless of its origin. So
 we talk about how it behaves differently depending on how it was
 constructed.

 I don't have a good idea for what is more "correct". The current
 documentation indicates exactly that.. it describes what happens when
 the `ZoneWriter` was constructed both ways. If you feel this is not
 good, please tell me how it should be updated and I'll change it.

 > With the code Jinmei deems unsafe, I think it is OK to know it never
 > throws. But it should be marked there as a comment, because it's not
 > obvious.

 There is a lot of Python API code that we call which are C functions and
 don't throw. I don't think it's necessary to point this out every
 time. But in the aim of progressing this ticket, I've added such a
 comment.

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