BIND 10 #1485: IOAddress::getAddress() breaks the concept of the asiolink

[BIND 10 Development]

#1485: IOAddress::getAddress() breaks the concept of the asiolink
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  defect        |                       Status:
            Priority:  medium        |  reviewing
           Component:  dhcp          |                    Milestone:  DHCP-
            Keywords:                |  Kea0.9-alpha
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  3             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  3
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by muks):

 Hi Tomek

 I saw your message on Jabber this morning and looked at the `trac1485`
 branch.

 You probably already thought that I would ask for the ASIO includes to be
 removed from the public branch. :) This can be achieved by using a pimpl
 idiom. I've attached a commit to this ticket which does this. However this
 shows up other issues in the DNS code:

 * Although `dns_server.h` is not disted (and so will not produce ABI
 issues later), it directly uses ASIO functions/constants. From the
 documentation in `asiolink.h`, it is not very clear who is supposed to
 include the ASIO headers in this case. Is it the program code? Some of the
 headers say this, but I'm not sure if this is the intended approach. This
 needs to be resolved, and resolving this is a bigger task than this
 ticket.

 * Similarly for other bits of the code.

 * The `IOAddress(const asio::ip::address&)` constructor was removed in the
 patch, and it seems some parts of the DHCP code uses it. If the patch is
 adopted, this code needs to be updated. There is a sub-optimal workaround
 for this in the patch itself, but it can be fixed properly if it is going
 to be used in a hotspot.

 The changes to the asiolink library look fine. You may want a DHCP
 developer to review the DHCP code changes.

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