BIND 10 #2835: add interface to get properties of datasrc clients from ClientList

[BIND 10 Development]

#2835: add interface to get properties of datasrc clients from ClientList
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  UnAssigned
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130319
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 I've not completed review, but am providing some initial feedback.
 That will probably affect the rest of the review.

 '''client_list.h'''

 - On `MemorySegmentState`, in the originally proposed design
   (http://bind10.isc.org/wiki/SharedMemoryIPC) I intended the state is
   independent from whether it's a shared type of segment or not:
   UNUSED, INUSE, or WAITING.  If cache is disabled it will be UNUSED;
   if it's local, or is shared and already mapped, it will be INUSE;
   if it's shared and waiting for mapping info (file name, shared memory
   name, etc), it will be WAITING.  And, read-only applications such as
   b10-auth don't care segment type differences; it only needs to know
   that for WAITING segments it will get information from memmgr.  In
   that sense, current implementation is different from what was
   originally intended: MSS_LOCAL and MSS_MAPPED are specific to the
   corresponding segment type.  While the initial proposed design isn't
   an absolute norm, we can discuss it, but is there any reason for
   making the segment type specific?

 - In any case, I'm afraid "MSS" could be misunderstood especially
   because it's commonly used to mean "maximum segment size".  I'd name
   them a bit more specific at the risk of sounding verbose.

 - On `DataSourceStatus`, is there a reason that `state_` is
   modifiable?  I originally thought this would be most likely a
   read-only structure once constructed.

 - On `DataSourceStatus`: In the original plan (admittedly not clear in
   the ticket) I expected it would contain the memory segment type
   ("local", "mapped", and maybe some others like "shared").  That
   would be retrieved from `ZoneTableSegment` and would be used by
   memmgr in #2856.

 - On `DataSourceStatus`: Likewise, I thought we'd include a list (or
   set) of zone names to be cached into memory.  Again, that would be
   used by the memmgr in #2856.  I'm not really sure about this,
   though...if it contains a large number of zones, returning a copy of
   it would be too heavy.  Maybe it's better to revise the zone writer
   and its getter so we can tell it to "load everything".  In that case
   this list (or set) doesn't have to be included in `DataSourceStatus`.

 - In general, we need a blank line before a "\brief" line.

 '''client_list.cc'''

 - `name` can be a reference here:
 {{{#!cpp
             const string name(name_elem ? name_elem->stringValue() :
 type);
 }}}

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