BIND 10 #1183: data source refactor refactor

[BIND 10 Development]

#1183: data source refactor refactor
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jelte
                       Type:  task   |                Status:  closed
                   Priority:  major  |             Milestone:
                  Component:  data   |  Sprint-20110830
  source                             |            Resolution:  complete
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:         |  Estimated Difficulty:  0
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:9 jelte]:

 > > Looks good, and I now wonder whether it's okay to call getNext() after
 > > it returns false.  We could either make it no-op or throw an
 > > exception, but if it currently causes any disruption such as segfault
 > > we should prevent that.  Also, it should be included in the abstract
 > > level interface.
 > >
 >
 > returning false again seems most natural (even though it is really a
 programming
 > error, false for 'yeah yeah you are still done' seems more logical to
 me).
 > Putting it in the abstract might be a tad difficult if we don't have a
 virtual
 > implementation :)

 Ah, sorry, I was not clear enough.  I meant describing this behavior
 in the base class documentation so that all derived class
 implementation follows it.  Suggested text is:

 {{{
          * Once this function returns false, any subsequent call to it
 should
          * result in false.  The implementation of a derived class must
 ensure
          * it doesn't cause any disruption due to that such as a crash or
          * exception.
 }}}

 If this looks okay, I'll push it to the master (as this is a simple
 documentation-only fix).

 And, now I happen to make a followup comment on this function, here's
 another thing:

 {{{
          * \note The order of RRs is not strictly set, but the RRs for
 single
          * RRset must not be interleaved with any other RRs (eg. RRsets
 must be
          * "together").
 }}}

 On further thought, we may need this property if and when we implement
 "ixfr-from-differences" (and I think we want to implement it), so,
 although it may still be too strict to request it for all derived
 classes, it would be better to suggest ensuring it when possible at
 least for the "iteration" case.

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