BIND 10 #2355: DHCP v4 and v6 parsers' unification should be considered

[BIND 10 Development]

#2355: DHCP v4 and v6 parsers' unification should be considered
----------------------------------------+----------------------------------
                   Reporter:  tomek     |                 Owner:
                       Type:  defect    |                Status:  new
                   Priority:  medium    |             Milestone:  DHCP 2012
                  Component:  dhcpconf  |            Resolution:
                   Keywords:            |             Sensitive:  0
            Defect Severity:  N/A       |           Sub-Project:  DHCP
Feature Depending on Ticket:            |  Estimated Difficulty:  0
        Add Hours to Ticket:  0         |           Total Hours:  0
                  Internal?:  0         |
----------------------------------------+----------------------------------

Comment (by tomek):

 Stephen wrote an interesting proposal, it should be considered:

 Regarding the parser code, assuming that the same form of parsing is
 used for both DHCP4 and DHCP6 (i.e. creating parsers for each
 component), then common parsers can be hung off a base class and used by
 both.

 {{{
 DhcpConfigParser
   |
 Uint32Parser
 StringParser
 InterfaceListParser
 }}}

 The pool parser could also be common if it were templated:

 PoolParser<typename PoolX, typename PoolXPtr, typename creator>

 ... where X is 4 or 6.  "creator" is a stand-alone function with two
 signatures:

 PoolXPtr creator(string, len)
 PoolXPtr creator(IOAddress, IOAddress)

 This function could itself be templated:

 {{{
 template <typename Arg1Type, typename Arg2Type>
 Pool6Ptr Pool6Creator(Arg1Type arg1, Arg2Type arg2) {
     return (Pool6Ptr(new Pool6(Pool6::TYPE_IA, arg1, arg2)));
 }
 }}}

 The same could also go for SubnetParser. Of course, the problem comes in
 issues like the call to createSubnet6ConfigParser etc.  I think that
 could be solved using an inheritance hierarchy like:

 {{{
 DhcpConfigParser
     :
 SubnetParser<pool6 parameters>
     :
 Subnet6Parser
 }}}

 A little restructuring could put the common things (like the parsing the
 subnet specification) in the SubnetParser class, and the specific things
 (parsing subnet-specific parameters) in the derived class.

 Stephen

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