[2269] Developer's guide updated.

doc/devel/mainpage.dox

@@ -15,12 +15,17 @@
  * <a href="http://bind10.isc.org/">BIND10 webpage (http://bind10.isc.org)</a>
  *
  * @section DNS
+ * - Authoritative DNS (todo)
+ * - Recursive resolver (todo)
  * - @subpage DataScrubbing
  *
  * @section DHCP
  * - @subpage dhcpv4
  *   - @subpage dhcpv4Session
  * - @subpage dhcpv6
+ *   - @subpage dhcpv6-session
+ *   - @subpage dhcpv6-config-parser
+ *   - @subpage dhcpv6-config-inherit
  * - @subpage libdhcp
  *   - @subpage libdhcpIntro
  *   - @subpage libdhcpIfaceMgr

src/bin/dhcp6/dhcp6.dox

 /**
- * @page dhcpv6 DHCPv6 Server Component
- *
- * BIND10 offers DHCPv6 server implementation. It is implemented as
- * b10-dhcp6 component. Its primary code is located in
- * isc::dhcp::Dhcpv6Srv class. It uses \ref libdhcp extensively,
- * especially lib::dhcp::Pkt6, isc::dhcp::Option and
- * isc::dhcp::IfaceMgr classes. Currently this code offers skeleton
- * functionality, i.e. it is able to receive and process incoming
- * requests and trasmit responses. However, it does not have database
- * management, so it returns only one, hardcoded lease to whoever asks
- * for it.
- *
- * DHCPv6 server component does not support relayed traffic yet, as
- * support for relay decapsulation is not implemented yet.
- *
- * DHCPv6 server component does not use BIND10 logging yet.
- *
- * @section dhcpv6Session BIND10 message queue integration
- *
- * DHCPv4 server component is now integrated with BIND10 message queue.
- * It follows the same principle as DHCPv4. See \ref dhcpv4Session for
- * details.
-  
+ @page dhcpv6 DHCPv6 Server Component
+
+ BIND10 offers DHCPv6 server implementation. It is implemented as
+ b10-dhcp6 component. Its primary code is located in
+ isc::dhcp::Dhcpv6Srv class. It uses \ref libdhcp extensively,
+ especially lib::dhcp::Pkt6, isc::dhcp::Option and
+ isc::dhcp::IfaceMgr classes. Currently this code offers skeleton
+ functionality, i.e. it is able to receive and process incoming
+ requests and trasmit responses. However, it does not have database
+ management, so it returns only one, hardcoded lease to whoever asks
+ for it.
+
+ DHCPv6 server component does not support relayed traffic yet, as
+ support for relay decapsulation is not implemented yet.
+
+ DHCPv6 server component does not use BIND10 logging yet.
+
+ @section dhcpv6-session BIND10 message queue integration
+
+ DHCPv4 server component is now integrated with BIND10 message queue.
+ It follows the same principle as DHCPv4. See \ref dhcpv4Session for
+ details.
+
  @section dhcpv6-config-parser Configuration Parser in DHCPv6
 
  b10-dhcp6 component uses BIND10 cfgmgr for commands and configuration. During
- initial configuration (See \ref ControlledDhcpv6Srv::establishSession()),
- the configuration handler callback is installed 
- (see ControlledDhcpv6Srv::dhcp6ConfigHandler(). It is called every time there
- is a new configuration. In particular, it is called every time during daemon
- start process. It contains a ConstElementPtr to a new configuration. This
- simple handler calls \ref isc::dhcp::configureDhcp6Server() method that
- processes received configuration.
+ initial configuration (See \ref
+ isc::dhcp::ControlledDhcpv6Srv::establishSession()), the configuration handler
+ callback is installed (see isc::dhcp::ControlledDhcpv6Srv::dhcp6ConfigHandler().
+ It is called every time there is a new configuration. In particular, it is
+ called every time during daemon start process. It contains a
+ isc::data::ConstElementPtr to a new configuration.  This simple handler calls
+ \ref isc::dhcp::configureDhcp6Server() method that processes received configuration.
 
- This method iterates over list of received configuration elements and creates
- a list of parsers for each received entry. Parser is an object that is derived
- from a \ref Dhcp6ConfigParser class. Once a parser is created (constructor),
- its value is set (using build() method). Once all parsers are build, the
- configuration is then applied ("commited") and commit() method is called.
+ This method iterates over list of received configuration elements and creates a
+ list of parsers for each received entry. Parser is an object that is derived
+ from a \ref isc::dhcp::Dhcp6ConfigParser class. Once a parser is created
+ (constructor), its value is set (using build() method). Once all parsers are
+ build, the configuration is then applied ("commited") and commit() method is
+ called.
 
- All parsers are defined in src/bin/dhcp6/config_parser.cc file. Some
- of them are generic (e.g. \ref Uint32Parser that is able to handle
- any unsigned 32 bit integer), but some are very specialized
- (e.g. \ref Subnets6ListConfigParser parses definitions of Subnet6 lists). In
+ All parsers are defined in src/bin/dhcp6/config_parser.cc file. Some of them
+ are generic (e.g. \ref isc::dhcp::Uint32Parser that is able to handle any
+ unsigned 32 bit integer), but some are very specialized (e.g. \ref
+ isc::dhcp::Subnets6ListConfigParser parses definitions of Subnet6 lists). In
  some cases, e.g. subnet6 definitions, the configuration entry is not a simple
- value, but a map or a list itself. In such case, the parser iterates over
- all elements and creates parsers for a given scope. This process may be
- repeated (sort of) recursively.
- 
+ value, but a map or a list itself. In such case, the parser iterates over all
+ elements and creates parsers for a given scope. This process may be repeated
+ (sort of) recursively.
+
  @section dhcpv6-config-inherit DHCPv6 Configuration Inheritance
 
  One notable useful features of DHCP configuration is its parameter inheritance.
- For example, renew-timer value may be specified at a global scope and it
- then applies to all subnets. However, some subnets may have it overwritten
- with more specific values that takes precedence over global values that are
- considered defaults. Some parsers (e.g. \ref Uint32ConfigParser and
- \StringParser) implement that inheritance. By default, they store values in
- global uint32_defaults and string_defaults storages. However, it is possible
- to instruct them to store parsed values in more specific storages. That
- capability is used, e.g. in \ref Subnet6ConfigParser that has its own storage
- that is unique for each subnet. Finally, during commit phase (commit() method), 
- appropriate parsers can use apply parameter inheritance.
+ For example, renew-timer value may be specified at a global scope and it then
+ applies to all subnets. However, some subnets may have it overwritten with more
+ specific values that takes precedence over global values that are considered
+ defaults. Some parsers (e.g. \ref isc::dhcp::Uint32Parser and \ref
+ isc::dhcp::StringParser) implement that inheritance. By default, they store
+ values in global uint32_defaults and string_defaults storages. However, it is
+ possible to instruct them to store parsed values in more specific
+ storages. That capability is used, e.g. in \ref isc::dhcp::Subnet6ConfigParser
+ that has its own storage that is unique for each subnet. Finally, during commit
+ phase (commit() method), appropriate parsers can use apply parameter inheritance.
 
  Debugging configuration parser may be confusing. Therefore there is a special
- class called \ref DummyParser. It does not configure anything, but just accepts
- any parameter of any type. If requested to commit configuration, it will print
- out received parameter name and its value. This class is not currently used,
+ class called \ref isc::dhcp::DummyParser. It does not configure anything, but just
+ accepts any parameter of any type. If requested to commit configuration, it will
+ print out received parameter name and its value. This class is not currently used,
  but it is convenient to have it every time a new parameter is added to DHCP
  configuration. For that purpose it should be left in the code.
 
@@ -76,5 +77,3 @@
  do not implement any fancy inheritance logic.
 
  */
-
-