BIND 10 #1069: combine resolver ACL context with generic request context

[BIND 10 Development]

#1069: combine resolver ACL context with generic request context
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110712
                  Component:         |            Resolution:
  resolver                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:3 jinmei]:
 > Some points that may warrant discussions:
 >
 > - I fully simplified RequestContext.  It currently only consists of
 >   a member for the remote IP address.  The rationale is documented
 >   in the commit log of d2dc7a3ef911a5ab83527753f351bc99440d60fe.
 >   Other background point is that I wanted to minimize dependency on
 >   other modules.  This is one reason why I used IPAddress instead of
 >   asiolink::IOAddress (and yet another reason specific to IOAddress is
 >   handling IOAddress is expensive).

 Well, the motivation for having the members there was to minimise need to
 change it (and therefore the interface) later. Also, we're planning to
 allow users plugging in their own ACL checks, so it would be nice if they
 were provided with the information they need.

 However, I don't mind leaving this decision (eg. what members to put
 there) to later time.

 > - When we introduce a parameter for the TSIG key in RequestContext, I
 >   suspect std::string for TSIG keys wouldn't be the best choice

 OK, I just guessed at the time of writing it.

 Anyway, few minor things:
  * Is this needed? There's a typedef for the same in the isc::acl:
 {{{
 typedef isc::acl::ACL<isc::acl::dns::RequestContext> QueryACL;
 }}}
  * Is there a double negative?
 {{{
      * No exceptions from \c loadCheck (therefore from whatever creator is
      * used) and from the actionLoader passed to constructor are not
 caught.
 }}}
  * Maybe calling explicit `FAIL()` in getSockAddr as well as returning the
 dummy value, to explain why it failed?

 With regards

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