BIND 10 #2018: Use updater's finder in DDNS

[BIND 10 Development]

#2018: Use updater's finder in DDNS
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120612
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  3
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:11 jinmei]:
 > Replying to [comment:10 jelte]:
 >
 > The branch now basically looks okay for merge.
 >
 > One nit: I'd personally clarify the operator preference between `|` and
 > `=` here:
 > {{{#!python
 >     def find(self, name, rrtype,
 >              options=ZoneFinder.NO_WILDCARD | ZoneFinder.FIND_GLUE_OK):
 > }}}
 > this way:
 > {{{#!python
 >     def find(self, name, rrtype,
 >              options=(ZoneFinder.NO_WILDCARD |
 ZoneFinder.FIND_GLUE_OK)):
 > }}}
 >
 > but that's a matter of taste, so I'd leave it to you.  If you make
 > this change, please also do it for find_all().
 >

 ok, done

 > > > Okay, and this reminds me of another thing.  For the "smarter"
 > > > behavior, I guess another approach is
 > > > [...]
 > >
 > > That is another reasonable approach, I have some doubts about whether
 it would be much better though; I suspect (note, not 100% sure) that in
 essence, to create the diff, you'll have to do nearly everything we now
 have to do anyway (even if you update directly), and I would be worried
 that the locally built diff could get out of sync with what has actually
 been sent to the updater. So in order to have that reasonably, i'd think
 we'd actually get a quite similar abstraction as the current Diff to
 handle that.
 >
 > I see this concern.  This is just food for thought; I'm not
 > necessarily insisting the BIND 9's approach here.  We should just
 > consider various possible approaches and just choose the best one that
 > meets our goal.
 >

 ack. Discussion will probably continue in #2016 :p

 >
 > > > But, again, these will be beyond the scope of this ticket.  My
 > > > personal suggestion is to keep the current (RFC-described) ordering
 > > > just in this task, and defer this clarification with doc to a
 separate
 > > > task.  But, assuming that no one will object to the eventual
 behavior
 > > > of BIND 10, if you really want to make this change now, I don't
 oppose
 > > > to that.
 > >
 > > ok, moving it back down :)
 >
 > And we'll create a ticket for that?

 ack, done (#2027)

 assigning back for final ack.

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