BIND 10 #1975: implement meta-or-container-of data source

[BIND 10 Development]

#1975: implement meta-or-container-of data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120619
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  9
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:15 jinmei]:
 > > How does this help? Notice that the result contains the number of
 matched labels as well, so we should call it for the first DS too. Or, do
 you want to get rid of that part of result?
 >
 > Ah, right, I overlooked it.  Hmm, with correcting that, I was about to
 > okay with it...but on thinking it further, I realized `getOrigin()`
 > may not be always cheap when we adopt memory-efficiency data structure
 > for in-memory cache.  The origin name may be encoded in some
 > memory-efficient form and getOrigin() call may require constructing a
 > Name object from it.  Maybe my concern is premature, but if we don't see
 a
 > specific need for returning the label, I'm inclined to omit it from
 > the result structure (after all, if the caller really needs it, it can
 > then call getOrigin()->getLabelCount() itself), and optimize the
 > find() code so it doesn't have to call getOrigin() for the first
 > partial match case.

 I changed it. But I fear it will grow complex when the support for caches
 in front of the data sources appear, because in some cases, we will not
 create the finder.

 > > The `PARTIALMATCH` needs the curly braces, since it contains a
 variable. So I added it to the other cases too, for consistency. Is there
 a reason not to have them, when we have them for single-line if too?
 >
 > Does it really need braces?  The scope of the variable is the inner if
 > block, so I don't think brace is required here.  In fact, it compiles
 > perfectly fine for me without braces.

 Obviously, it doesn't now. So it must have been some previous version of
 my code.

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