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-20130402
         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:

 Hello

 So I found little bit of time to look at this.

 Replying to [comment:12 jinmei]:
 > '''changelog'''
 >
 > The fact that data source can be named may be worth noting, but I'd
 > leave it to you.

 So, something like:

 {{{
 Data sources can be explicitly named, using the "name" option. This
 doesn't
 have any practical benefit yet, but we expect it to use in near future.
 The
 names must be unique. As they are based on the type of data source, you
 may
 need to explicitly set it in rare cases.
 }}}

 > '''datasrc.spec.pre.in'''
 >
 > - IIRC, an optional item must have a default (otherwise, e.g., bindctl
 >   doesn't work correctly with it), although I may be wrong - the
 >   concept of "optional" has always confused me.

 I couldn't test (I'm using a very slow netbook, and I don't have the time
 to
 compile full bind10 ☹). But, from logical point of view, a default makes
 no
 sense with optional item.

 If you have default, it is the value that an item gets when it is born.
 So, you
 can either set it to something else, or leave it out.

 With optional item, it may or may not be present in the map. Default for
 something that doesn't exist makes no sense and it is created by setting
 it to
 some explicit value.

 I think the spec validator did require default before, but that was fixed.
 And
 what AFAIK doesn't work is deleting the optional item (eg. unset is
 broken).

 > - `MemorySegmentType`: I'm not sure if we define them here.  In my
 >   image specific details of segment types are private to memory
 >   segment (and corresponding `ZoneTableSegment`) implementations, and
 >   the `ClientList` class uses it transparently.  So, for example, we
 >   might allow introducing another type of memory segment as a plugin
 >   in future.  For that reason my original intent is to define the type
 >   in a semantics-free type, such as a plan std::string.

 Hmm. Passing these kinds of things as strings doesn't feel right either,
 but it
 might be the lesser evil.

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