BIND 10 #1608: implement ZoneFinder::Context::getAdditional() for in memory data source

BIND 10 Development do-not-reply at isc.org
Sat Mar 10 07:51:49 UTC 2012


#1608: implement ZoneFinder::Context::getAdditional() for in memory data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:  high   |  Sprint-20120320
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  auth   |           Total Hours:  0
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 trac1608 is ready for review.

 The first two commits are setup for subsequent change and they should
 be straightforward (while the size of diff is big).  So it may be
 easier to review separately (then the size of the remaining diff will
 be a more focused one).

 The changes around InMemoryZoneFinder::Context and
 InMemoryZoneFinder::load() are the main changes for the branch.  I
 believe the former is basically straightforward.  The latter may
 require some patience...hopefully the comments are clear.  The rest of
 the changes are basically for adjusting the interface.

 There's one open issue: the current implementation cannot handle the
 case where the name of an additional record requires wildcard match.
 It's tested in getAdditionalDelegationWithWild and disabled for
 in-memory for now.  I could address this within this branch, but it's
 now getting quite big, and the case should be very minor (and the
 solution wouldn't be trivial), so I propose completing the current set
 first and defer the wildcard case to a separate ticket.

 Due to this minor regression we may need a changelog entry for this,
 but expecting we'll address this before the next release, I'd omit it
 for now.  The change should be otherwise transparent (except for the
 better performance, but for that we'll probably create a single
 unified changelog entry).

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


More information about the bind10-tickets mailing list