BIND 10 #2975: Create initial DnsClient class

[BIND 10 Development]

#2975: Create initial DnsClient class
-------------------------------------+-------------------------------------
            Reporter:  tmark         |                        Owner:  tmark
                Type:  enhancement   |                       Status:
            Priority:  medium        |  reviewing
           Component:  dhcp-ddns     |                    Milestone:
            Keywords:                |  Sprint-DHCP-20130717
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by tmark):

 Review Comments:

 Really I only have a few comments.  Good job on this.

 General:

 * From a naming standpoint it is somewhat confusing for DNSClient to
 derive from IOFetch::Callback and have an embedded class named Callback
 and member callback_.

 Perhaps changing the name of the instance member from callback_ to
 client_callback_  or external_callback_.  You could call
 DNSClient::Callback something like ResponseHandler.

 * Question: - " Caller must provide a callback, which will be invoked when
 the response from the DNS server is received, a timeout has occured or IO
 service has been stopped for any
 reason. "

 What if the address given is bad, or there is a network error, like a
 disconnect of some kind other than timeout?  I notice the IOFetch::Result
 doesn't provide a value for this.   "Stopped" should only happen if the
 IOService is stopped which an IO error should not cause.

 * Am guessing the @todo for DNSClient::operator() is being done under
 2977?

 * As per our discussion, providing a protocol selection parameter for
 TCP/UDP would be good, and we need to think about TSIG as well.  Meaning
 that, perhaps we need a variant of update which accepts a TSIGKey
 parameter?  Initial release will not implement actual TSIG,but the
 interface could accommodate it.

 * Minor pick - spell check, Marcin.  You have several misspellings in the
 commentary.  I use GVIM to do my spell checking ;)


 Also I have taken the liberty to attach a class diagram for you:

 [[Image(dns_client.svg)]]

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