BIND 10 #2853: Python wrapper of data source extensions

[BIND 10 Development]

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

 * owner:  vorner => muks


Comment:

 Hello

 Replying to [comment:28 muks]:
 > 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.

 Well, for one, I don't think we want to include the exact name of the
 flag, since it's not visible to python at all. I'd say something like
 „Depending on how the object is created, it either throws on error or
 returns a string. The only way to create it currently is by calling
 get_cached_zone_writer(), which creates in the throw mode“ or something
 like that (not sure about the mode it is in).

 > > 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.

 Actually, the C function is not what is unclear. The `getName` is not
 obvious it doesn't throw, because it's a C++ function.

 I don't really have an opition on the points from Jinmei. On one side,
 using the containers is added complexity, on the other, the implicit error
 propagation might be confusing too.

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