BIND 10 #1512: implement zone section processing in DDNS

[BIND 10 Development]

#1512: implement zone section processing in DDNS
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:  task   |                Status:  reviewing
                   Priority:         |             Milestone:
  medium                             |  Sprint-20120529
                  Component:  DDNS   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:  DDNS   |  Estimated Difficulty:  6
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:14 vorner]:

 > > > What is the motivation to have classes for formatting data
 (`ZoneFormatter` and `ClientFormatter`)? If it is performance, is it
 really faster to allocate the new python object than to do the actual
 conversion?
 > > But you might think any of these are just premature.  In that case I'm
 > > also okay with always converting them to string.
 >
 > It is probably premature, but as it is already written this way, I think
 it is OK to just add a comment there, explaining, and be done with it.

 [...]

 > So, except for the comment above, I think it is OK to merge. Would you
 add it and merge, if you agree?

 Okay, I've added comments and pushed it.  If you could check it that
 would be appreciated, but if you don't see the need for it, please
 just ignore.  In either case I'll merge the branch soon (unless you
 check it and find a problem).

 > > {{{
 > > AssertionError: <pydnspp.Opcode object at 0x1018bbd50> !=
 <pydnspp.Opcode object at 0x1018bbd10>
 > > }}}
 > >
 > > On the other hand, I admit it's counter intuitive.  I've added a
 > > simple comment about the intent, but I'm also okay with removing
 to_text().
 >
 > A comment is good for now. I think the Opcode, and others, should have
 working __str__ method in the long term, so we wouldn't need these kinds
 of hacks, but it's out of the scope here. If you agree it would be good,
 would you create a ticket?

 Opcode (and also others, in general) already supports `__str__`.

 {{{
 >>> isc.dns.Opcode.UPDATE().__str__()
 'UPDATE'
 }}}

 I has been a mystery to me why the output from assertXXX() is still so
 unhelpful.

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