BIND 10 #2833: refactor relationship between datasrc::ClientList and ZoneTableSegment

[BIND 10 Development]

#2833: refactor relationship between datasrc::ClientList and ZoneTableSegment
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |                       Status:  new
            Priority:  medium        |                    Milestone:  Next-
           Component:  Unclassified  |  Sprint-Proposed
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> subtask of #2830.  depend on #2832.
>
> not directly related, but IMO will be a helpful cleanup for later
> development.
>
> The basic motivation is to make `ClientList` (and `InMemoryClient`)
> segment-type agnostic as much as possible.
>
> Feature wise what we'll do is
>
> - create separate zone table segment for each client
> - pass specific config (maybe reorganize it) to
>   `ZoneTableSegment::create`.  specifically, we pass
>   cache-segment-type, cache-segment-params, and cache-zones.
>   in case of `MasterFiles`, cache-zones should be created from
>   its own param.  also pass "load param", which is, in case of
>   `MasterFiles`, its own param (zone name to file map)
> - also pass a `GetLoadAction` functor to create (we need to extend
>   it).  which would look like:
> {{{
> typedef boost::function<LoadAction(const Name& zone_name, ConstElementPtr
> param)> GetLoadAction;
> }}}
>   For `MasterFiles`, param will be ignored, and something similar to
>   `loadZoneDataFromFile` will be used.  For others, the returned
>   functor would encapsulate the underlying data source client so it
>   can create an iterator on actual load.
> - if necessary (e.g. in case of local) the actual zone table segment
>   implementation iterates over the cache-zones, and call the given
>   GetLoadAction with the name and "load param" part of the config.
> - extend the zone table segment class adding the "loadAll" method
>   (virtual).  the behavior differs depending on the characteristics of
>   the segment.  if necessary (e.g. in case of local) the actual zone
>   table segment implementation iterates over the cache-zones, and call
>   the given GetLoadAction with the name and "load param" part of the
>   config. It then uses the `ZoneWriter` with the returned `LoadAction` to
>   actually load the data into the segment.  But in the case of "read
>   only" shared memory/mapped segment, it will do nothing at this
>   point.  the "load" will be a mapping operation that will happen
>   later (information given by the memmgr).
>
> Also, cache-zones list and load params may be kept inside the table
> segment in case of reload.
>
> The main point of these changes is to move the decision of whether to
> actually load from `ClientList` to the segment manager.  It will also
> allow (later) to remove file lists from `MemoryClient`.

New description:

 subtask of #2830.  depend on #2832.

 not directly related, but IMO will be a helpful cleanup for later
 development.

 The basic motivation is to make `ClientList` (and `InMemoryClient`)
 segment-type agnostic as much as possible.

 Feature wise what we'll do is

 - create separate zone table segment for each client
 - pass specific config (maybe reorganize it) to
   `ZoneTableSegment::create`.  specifically, we pass
   cache-segment-type, cache-segment-params, and cache-zones.
   in case of `MasterFiles`, cache-zones should be created from
   its own param.  also pass "load param", which is, in case of
   `MasterFiles`, its own param (zone name to file map)
 - also pass a `GetLoadAction` functor to create (we need to extend
   it).  which would look like:
 {{{
 typedef boost::function<LoadAction(const Name& zone_name, ConstElementPtr
 param)> GetLoadAction;
 }}}
   For `MasterFiles`, param will be ignored, and something similar to
   `loadZoneDataFromFile` will be used.  For others, the returned
   functor would encapsulate the underlying data source client so it
   can create an iterator on actual load.
 - if necessary (e.g. in case of local) the actual zone table segment
   implementation iterates over the cache-zones, and call the given
   GetLoadAction with the name and "load param" part of the config.
 - extend the zone table segment class adding the "loadAll" method
   (virtual).  the behavior differs depending on the characteristics of
   the segment.  if necessary (e.g. in case of local) the actual zone
   table segment implementation iterates over the cache-zones, and call
   the given GetLoadAction with the name and "load param" part of the
   config. It then uses the `ZoneWriter` with the returned `LoadAction` to
   actually load the data into the segment.  But in the case of "read
   only" shared memory/mapped segment, it will do nothing at this
   point.  the "load" will be a mapping operation that will happen
   later (information given by the memmgr).

 Also, cache-zones list and load params may be kept inside the table
 segment in case of reload.

 The main point of these changes is to move the decision of whether to
 actually load from `ClientList` to the zone table segment.  It will also
 allow (later) to remove file lists from `MemoryClient`.

--

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