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-20110223
                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        |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 vorner]:

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

 Okay, changed.

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

 (I've added one more "0" to the value, which was the originally intended
 value as I explained)

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

 Admittedly, not fully thought about it, and it's not even clear if
 we'll be able to have 28 bits for this purpose.  What I roughly
 imagined is that we have two types of trees, one of which is
 specifically designed for very large zones with a separate node ID
 field, and have the administrator of such zones configure it
 accordingly and manually (based on the observation that over 200M
 nodes should be sufficient for the vast majority).  But this may not
 be a good idea in the end, especially when the zone can dynamically
 grow via IXFR or dynamic update.

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

 Okay, now merging, and closing the ticket.  Thanks for the review.

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