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

[BIND 10 Development]

#1608: implement ZoneFinder::Context::getAdditional() for in memory data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       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:  3
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei
 * totalhours:  0 => 3


Comment:

 In general, the code looks ok, I do have a couple of comments;

 - The two mappings of DomainNode::FLAG_USER are defined in different
 scopes. This may not be a problem (and in fact, defining them each in the
 smallest context as possible can be argued for), but it does feel like an
 abstraction violation, and I wonder if we shouldn't make define them in
 the same place.

 - Do we want to support additional data and glue that is defined outside
 of this zone, but available to the system (i.e. in a different zone, or
 maybe a different data source)? Esp. from a different data source would
 require more memory (and scary reverse dependencies), since that can't
 simply point to existing memory, but if we use a 'real' lookup for the
 actual additional data, but we'd get wildcard matching for 'free'. But
 even for just the one in-mem datasource, we'd also need some way to reset
 them for any zone (if a child zone gets loaded later), even if we don't do
 dynamic updating of zone data. The answer may be 'no' :) (and if yes, out
 of scope for this ticket). Oh, and if 'no'; should we warn or error or
 missing needed glue?

 - This comment suggests we are doing things that are very very dirty:
 {{{
 This is public only because it needs to be used outside
 // of the \c RBNodeRRset class, but conceptually this is a private type.
 }}}
 It's less ugly than the comment would suggest, but still :) (private for
 whom, for instance) Any specific reason to prefer this over an abstract
 base class?

 - One of the lettuce tests fails too (nsec3_auth.feature scenario 5; fails
 on the now missing glue from wildcards). We can temporarily change that
 one as well, but we should give a high priority to fixing this

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