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:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by 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().

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

 > *ideally* i still think it would be best if the zoneupdater would just
 take anything in any order and keep track of changes itself :P
 >
 > BTW I am starting to think that maybe we should not have reused
 xfrin.diff.Diff for these single-updates; nearly every operation either
 needs a different handler or it is only valid for one type. Thinking of
 splitting them up into two classes, with perhaps a base class for some of
 the internals (like setting up the updater).

 That may be true.

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

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