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          |  vorner
            Priority:  medium        |                       Status:
           Component:  Unclassified  |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130423
         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):

 Replying to [comment:13 vorner]:

 > Just to check, the current cache loads no dynamic module? So it works
 with static linking?

 Correct, and yes.  I confirmed it worked with a static-link build on
 MacOS (which would normally cause this regression).

 > I believe calling a wrong type of value a syntax error might be slightly
 confusing. Usually, when someone talks about syntax errors, I imagine
 something like missing parentheses or such. Wrong type of value looks more
 like semantic error.
 >
 > {{{#!c++
 >     /// For other data source types than "MasterFiles", cache can be
 disabled.
 >     /// In this case cache-zones configuration item is simply ignored,
 even
 >     /// it contains a syntax or semantics error.
 > }}}

 Hmm, calling it a semantics error doesn't sound quite right to me
 either, and at this point errors like a missing parenthesis shouldn't
 happen, which is one of few things that the weakly-typed
 `data::Element` class can ensure.  But in any case, I tried to updated
 the doc without using the controversial word of "syntax".

 > It says the `datasrc_conf` is „system-wide“ configuration. What does it
 mean? Is there some kind of local configuration?

 I admit it was not clear.  I tried to clarify it.

 > Here, the param `config` is probably outdated. There's no such parameter
 any more.
 > {{{#!c++
 >     /// \param rrclass The RR class of the zones to be maintained in the
 table.
 >     /// \param config The configuration based on which a derived object
 >     ///               is returned.
 >     /// \return Returns a ZoneTableSegment object
 > }}}

 Ah, good catch, fixed.

 > The zero here should be `NULL`:
 > {{{#!c++
 >  prepareSource(Name::ROOT_NAME(), 0);
 > }}}

 Actually, since the discussion on whether to allow direct evaluation
 of pointers as boolean, I've been inclined to use 0 rather than the
 macro of `NULL`.  "The C++ Programming Language" also suggests:
 "Because of C++'s tighter type checking, the use of plain 0, rather
 than any suggested NULL macro, leads to fewer problems".  We actually
 saw an issue with `NULL` when we found we cannot use it to represent
 the NULL RR type.  In reality, it's less likely that we can completely
 be free from this type of troubles even if we stop using `NULL`
 internally, but I think it will still help reduce troubles.

 That said, such cleanup, even if agreed, is not in the scope of this
 task, and we are using `NULL` in many other places in our source code
 anyway, so I changed this particular one to `NULL`.  We should
 probably the generic issue separately in the ML and/or a team call.

 > In these files, the static data source was used because there was in-
 memory data source first and once it stopped being available directly,
 this was the easiest way to switch. Maybe we should switch back now and
 use master-files with some real zone and cache?

 Please see my previous "quick question" and clarify what this is
 about.

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