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

Comment (by jinmei):

 Replying to [comment:17 vorner]:

 The latest version looks okay for merge.

 Some final comments:

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

 For a bit longer term, I can think of several possibilities.

 We might separate the single data source case completely.  It would
 result in some duplicate code, but the entire find logic is relatively
 simple and the duplicate may be acceptable.  And each of the single
 and multi versions themselves will be much simpler.

 Alternatively, we might want to extend findZone() return the number of
 matched labels as well as code and finder, for possible optimizations.
 Also, we may want to extend the API so we have an interface just to
 see if a given zone exists in a specific data source with the ability
 of returning the matching number of labels.

 And, one more thing I forgot to respond to in the previous comment
 (not for the branch itself):

 > > - (note: I'm not requesting a change to this branch by this).  While
 > >   it's understandable to introduce the trick with `DataSourcePair` to
 > >   avoid handling `DataSourceClientContainer`, it seems to make the
 > >   code fragile; [...]  This seems to me
 > >   to indicate we need more flexibility for `DataSourceClientContainer`
 > >   as we discussed it in #1207 (see the second bullet for the factory.h
 > >   comments of http://bind10.isc.org/ticket/1207#comment:12).
 >
 > Yes, that would indeed be nice. A clean-up ticket, then?

 Yes, please.

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