BIND 10 #2209: define and implement ConfigurableClientList::getCacheZoneUpdater()

[BIND 10 Development]

#2209: define and implement ConfigurableClientList::getCacheZoneUpdater()
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121106
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:10 vorner]:

 The new changes look good.

 > I think it should be cleaned up, but the auth server still uses it now.
 I think
 > we'll remove it after we start using the background loading, since that
 one
 > will naturally switch to not use the reload() method.

 Then could you open a ticket for the cleanup?

 > > '''memory_client.cc'''
 > >
 > > - `InMemoryClient` constructor: it seems to be not exception safe
 > >   about zone_table_segment_.  This may become a non issue if you
 > >   migrate to the "formal" version of `ZoneTableSegment::create`, but
 > >   we should check that again.
 > >
 > > '''memory_client.h'''
 > >
 > > - `getZoneTableSegment()`: I guess we should eventually let
 > >   `ClientList` (or at least something outside of `InMemoryClient`)
 > >   directly manage `ZoneTableSegment`, at which point `InMemoryClient`
 > >   will probably take it as a parameter to the constructor.  But for
 > >   now I can live with this workaround.
 >
 > I guess both of these would be fixed once #2208 is merged into this,
 since this
 > code won't be present. Which should be pretty soon. If this code doesn't
 > disappear by then, I'll look into them.

 I'm not sure about the latter, but as I said I can live with it as an
 intermediate workaround.  For the former, I think we need to run one
 more review cycle after the cleanup.  BTW, #2208 now seems to be ready
 for merge.

 > > - not matter much, and may even become a non issue depending on what
 > >   to do with reload(), but I found TYPED_TEST is often heavy in
 > >   building (due to the use of template).  If we keep supporting both,
 > >   maybe we should consider value-parameterized test (TEST_P).  It's
 > >   particular so in this case because the use of different types seem
 > >   to be a hack just so they can be used in TYPED_TEST.
 >
 > Hmm. It seems that the size of change would not be really small and
 we'll
 > probably remove the reload() soonish. Then it would be better to just
 remove
 > the TYPED_TEST ones and unify the test fixture classes. I'd like to keep
 it
 > this way for the short time, since the time spent on compiling the
 templates
 > will definitely be smaller than the time I'd spend changing it.

 If the plan is to deprecate reload(), I'm okay with keeping the
 current style until then.

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