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 jelte):

 Replying to [comment:11 jinmei]:
  > > 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).
 >

 sure, go ahead

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

 it did cross my mind, but i wasn't sure whether we'd use 'normal' full
 iterate for that, as i figured it might need more restrictions for such a
 usage, and if they are heavy, perhaps we'd need a different type of
 iterator for that as well (optional for datasources that wouldn't want to
 support it). But i haven't fully thought about how to do this yet

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