BIND 10 #999: Integrate ACLs into b10-resolver

[BIND 10 Development]

#999: Integrate ACLs into b10-resolver
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110628
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:5 vorner]:
 > You might want to have a look at #769, it should contain the loader and
 convenience typedefs and the Context. It is not reviewed yet, but might be
 more useful than just guessing.

 Thanks for the pointer.  Some quick comments about the Packet structure:

 I've been thinking about the same concept for #999 and tentatively
 defined a class named "Client":

 {{{
 class Client {
 public:
     explicit Client(const isc::asiolink::IOMessage& request_message);
     ~Client();
     const isc::asiolink::IOEndpoint& getRequestSourceEndpoint() const;
     const isc::acl::IPAddress& getRequestSourceIPAddress() const;
 ...
 };
 }}}

 It's not a very strong opinion, but I suspect "Packet" sounds a bit
 too generic in that it could be either incoming/outgoing
 request/response, while this class seems to focus on the incoming
 side, e.g., from this:
 {{{
     /// \brief The local IP address (ours, of the interface where we
 received).
     asiolink::IOAddress local_address;
 }}}

 Being generic is not necessarily bad, especially if we also want to
 use it in outgoing context, but in that case the entire interface
 should be able to represent the concept reasonably.

 I (again tentatively) define the "Client" class in lib/server_common.
 I'm not sure how many things that depend on specific contexts would be
 reasonably defined under the acl namespace.  Also, the concept of
 "Packet" itself is not necessarily tied to access control.  By
 defining Client, I'd envision we'll eventually use it as a higher
 level interface between ASIO and actual (auth/resolver) server
 classes, that is, instead of getting a set of io_message,
 query_message, ... etc. in Resolver::processMessage(), we'd pass a
 "Client" object that encloses these types of parameters.

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