BIND 10 #2219: switch to memory-efficient version of in memory data source

[BIND 10 Development]

#2219: switch to memory-efficient version of in memory data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120925
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:9 jinmei]:
 > That's an NSEC3 test, right?  It's due to bugs in #2218 and will pass
 > once we merge both #2218 and #2219 (that's one of the failures I
 > mentioned in the "Final note" of my request-for-review comment).

 OK

 > I know it's an ugly hack, but I don't like to tweak the code further
 > within this branch.  If you don't like the current version because
 > it's susceptible to future changes, I propose either:
 > - just skip this hack for now.  it'll still work correctly while initial
 start up time can be doubled

 I'd be for skipping it and creating a ticket with some proposal to clean
 it up.

 > > I'm not sure about the meaning of this comment. Could you explain it
 little bit more, what is happening there?
 > >
 > > {{{
 > >         // If and when we allow non absolute label at the origin (e.g.
 for
 > >         // the convenience of out-of-zone glue handling), we first
 need to
 > >         // construct the absolute label sequence and then construct
 the name.
 > > }}}
 >
 > How about this:
 > {{{#!cpp
 >         // In future we may allow adding out-of-zone names in the zone
 tree.
 >         // For example, to hold out-of-zone NS names so we can establish
 a
 >         // shortcut link to them as an optimization.  If and when that
 happens
 >         // the origin node may not have an absolute label (consider the
 zone
 >         // is example.org and we add ns.noexample.org).  In that case
 >         // we first need to construct the absolute label sequence and
 then
 >         // construct the name.
 > }}}

 Now I understand :-). Please, include this longer comment.

 > > Also, I noticed some indentation that probably does not adhere to any
 style guide I've ever seen O:-).
 > > {{{#!diff
 > > -    return (ZoneFinderResultContext(code, createTreeNodeRRset(node,
 rrset,
 > > -
 rrclass, rename),
 > > +    return (ZoneFinderResultContext(code, createTreeNodeRRset(
 > > +                                        node, rdset, rrclass,
 options, rename),
 > >                                      flags, node));
 > > }}}
 >
 > Yeah that's a kind of "non standard" exception to keep lines shorter.
 > There are already some similar cases like this though.  If this looks
 > too awkward, an alternative would be:
 > {{{#!cpp
 >     return (ZoneFinderResultContext(code, createTreeNodeRRset(node,
 rdset,
 >                                                               rrclass,
 options,
 >                                                               rename),
 >                                     flags, node));
 > }}}

 Hmm, maybe the second would feel more like the rest of the code.

 > I know this branch contains too many small things (and some of them
 > were completely unrelated like pure style fixes).  And, in fact,
 > that's why I decided to skip one other update: migrate the static data
 > source implementation.  I wish I could have separated these, but it's
 > pretty difficult to predict how many things we need to adjust in an
 > integration task.

 I know it happens from time to time. I just wanted to say I'm not sure how
 thorough I managed to be. But I don't think I have a proposal how to
 improve
 that.

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