BIND 10 #2213: revise LoadZoneCommand::exec() of b10-auth to use the configurator thread

[BIND 10 Development]

#2213: revise LoadZoneCommand::exec() of b10-auth to use the configurator thread
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121106
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => UnAssigned
 * status:  assigned => reviewing


Comment:

 (piece of comment taken from #2212, about where the code should fill in
 the IN value for the optional class argument, if not provided)

 > Hmm, I'm okay with leaving the default handling to the builder per se,
 > but I'd like to avoid hardcoding the value. The default is given in
 > the spec, and the implementation should retrieve the default from it.
 > But to do so, it needs to be able to access ModuleCCSession, and
 > at least right now the builder doesn't have the access (and I'd like
 > to keep it that way so that the builder is as independent as
 > possible). I know it requires the reconstructing the message, but in
 > this case it's a simple name, class pair, so I think it's not a big
 > overhead for the sender.

 Yes, builder shouldn't have access to that data, and it could be placed in
 auth_srv.cc, or even main.cc right now.

 I've been looking into this, however, the command specification is pretty
 well-enclosed in the API (apart from validateCommand() it doesn't offer
 much atm). I thought about extending it to allow for getDefaultValue()
 similar to the existing one, since that one is really for config only. But
 doing so would really be a separate task in itself.

 And while the value would not be hard-coded, the name (and what defaults
 to fill in) would still be, so I am going to propose a different change,
 in a new ticket, and make it hardcoded here for now. In short, I want the
 validation itself to get an option to fill in defaults (so that both for
 config and commands you'll always know you should have this kind of data
 available, both for mandatory data and optional data that has defaults).
 IMHO this is a step that will be needed as part of a bigger refactor
 anyway, and a relatively easy one that gives us much for relatively little
 (though the diff would probably be pretty big, as it needs to either
 factor out and copy a lot of api, or change a lot of consts to non-
 consts).

 Anyway, this branch is ready for review :)

 Additional notes:

 - command.cc needs something to call to process the loadzone command;
 rather than expose the entire builder I chose to make a very simple
 loadZone() method in AuthSrv (that simply forwards it)
 - updated a few lettuce tests for the now new log message that is printed
 when reloading

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