BIND 10 #2376: define LoaderContext class

[BIND 10 Development]

#2376: define LoaderContext class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121120
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:10 jinmei]:
 > Now, on this particular one.  Looking at the interface again, I can
 > see it's possible, for example, that we just pass a functor for
 > `addRRset` and a callbacks object to `MasterLoader` as separate
 > parameters, if you meant something like that.  It may be especially so
 > now that we define callbacks as a separate class.

 Yes, that would look nicer I think. Or just a structure of three callbacks
 (one
 as the addRRset, other two as the error handlers) ‒ we could pass all
 three at
 once to the underlying routines and they would ignore the callbacks they
 don't
 need.

 And, it would be nice if the addRRset actually matched the one of
 ZoneUpdater
 (one has reference, and one a pointer). So we could just simply
 boost::bind the
 addRRset of the updater.

 > I guess the question is how we expect the concept of "loader context"
 > will be complicated, including more states.  In our current usage,
 > that's basically identical to the imaginary `addRRset` functor object,
 > so it may make more sense to skip the additional layer of the class.
 > On the other hand, if we anticipate the context can have more
 > complicated states, it probably makes more sense to define a separate
 > class (as we do now) than passing each of them as a parameter to
 > `MasterLoader`.

 I don't see what kind of state there could actually be.

 I'm not against moving to the mailing list. Will you start the thread or
 should I?

 > - I guess we can simply use true-false check for boost::function
 >   objects:
 > {{{#!cpp
 >         if (!error_ || !warning) {
 >             isc_throw(isc::InvalidParameter,
 >                       "Empty function passed as callback");
 >         }
 > }}}

 Well, I think that if we don't allow treating pointers like true-false and
 explicitly test for NULL, this is very similar. So I didn't adopt this
 one.

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