BIND 10 #550: wildcard handling for memory zone: load

[BIND 10 Development]

#550: wildcard handling for memory zone: load
-------------------------------------+-------------------------------------
                 Reporter:  jinmei   |                Owner:  jinmei
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:  A-Team-
                 Priority:  major    |  Sprint-20110209
                Component:  data     |           Resolution:
  source                             |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  5.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Replying to [comment:6 jinmei]:
 > Do you mean we should (be able to) do this
 >
 > {{{
 > DomainTree::Result result = domains.insert(wname.split(1), &node);
 > }}}
 >
 > instead of this?
 >
 > {{{
 >                 DomainTree::Result result;
 > [comment lines]
 >                 result = domains.insert(wname.split(1), &node);
 > }}}

 Well, yes, for the sake of consistance (I also prefer the way with
 parenthesis instead of equal sign, as it is clear the constructor is
 called, not assignment operator, but it doesn't matter).

 > I don't have a strong opinion.  If you (even slightly) prefer the
 > latter, I'll change it.

 I don't have any strong opinion either, it just caught my eye, and it
 looked strange to see it like that. If you can change it, it might be
 slightly nicer, but no reason to stop to review that again I guess.

 > This was because we don't need a copy object of the name in
 > addValidation() (unlike the add() itself, where we may modify the
 > name), and passing rrset->getName() as a (const) reference seemed
 > redundant (because it's part of another parameter, rrset), and because
 > in this case getName() of the rrset should be very cheap (it's quite
 > likely the rrset is actually a basic version of RRset, whose getName()
 > simply returns a reference to its internal object).

 ACK, the way it was it seemed shorter code, but who cares ;-).

 > >  - The flags in the Node, do we expect that we will have so many flags
 that uint32_t will be needed? And how was 0x8000000U chosen?
 >  - Finally, we may want to store the node "ID" for faster name
 >    compression by exploiting the RBTree structure.  For that purpose
 >    we might want to have e.g. 4 real flags and a 28-bit wide field for
 >    the ID (to store up to about 260M nodes).

 What if we have more of them? That seems like a limitation.

 > That said, these all are just possibilities and may be premature at
 > this stage.  So I don't mind beginning with a smaller width field.

 It doesn't really matter now, but if I ever would write the hybrid
 tree/radix tree backend, I wanted to save as much space as possible (to
 minimise data loads), so I was more wondering than anything else.

 Anyway, let's merge it, I guess.

-- 
Ticket URL: <https://bind10.isc.org/ticket/550#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development