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          |  jinmei
            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
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Replying to [comment:9 jinmei]:
 > - 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?

 Well, mostly I didn't understand the whole image. I didn't know there'll
 be the type as well as the state and it seemed to me the user might need
 to distinguish the remotely mapped segment from locally loaded one.

 With the type, it can be type-independent.

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

 I must admit I never heard that, but changing the prefix.

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

 No real reason, just that I thought it would change during the lifetime of
 the data source and didn't realize I'd create a new instance every time.
 Now removed.

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

 Hmm. OK, I'll omit it for now, lets see if it is needed.

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

 I seem to always forget it in case of very small classes and stuff like
 that.

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

 I found out that many people get confused about this. So, I think we
 should use it only in case there's some real performance benefit.
 Comparing what other we do in the configuration and how often it is run, I
 think this is not the place to sacrifice clarity to performance.

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