|
|
@@ -245,8 +245,9 @@ tokens (e.g. TOPLEVEL_JSON and TOPLEVEL_DHCP6). For complete list of available
|
|
|
starting contexts, see @ref isc::dhcp::Parser6Context::ParserType. The
|
|
|
Parse6Context::parse() method takes one parameter that specifies, whether the
|
|
|
data to be parsed is expected to have a generic JSON or the whole configuration
|
|
|
-(DHCP6). This is only a proof-of-concept, but similar approach can be implemented
|
|
|
-to parse only subnets, host reservations, options or basically any other elements.
|
|
|
+(DHCP6). This feature is currently mostly used by unit-tests (which often skip
|
|
|
+the '{ "Dhcp6": {' preamble), but it is expected to be soon used for parsing
|
|
|
+subnets only, host reservations only, options or basically any other elements.
|
|
|
For example, to add the ability to parse only pools, the following could be added:
|
|
|
|
|
|
@code
|
|
|
@@ -256,15 +257,15 @@ start: TOPLEVEL_GENERIC_JSON sub_json
|
|
|
;
|
|
|
@endcode
|
|
|
|
|
|
-The code on trac5036 branch contains the code definition and the
|
|
|
-Kea-dhcp6 updated to use that new parser. I'm sure that parser does
|
|
|
-not cover 100% of all parameters, but so far it is able to load all
|
|
|
-examples from doc/example/kea6. It is also able to parser # comments
|
|
|
-(bash style, starting at the beginning or middle of the line), //
|
|
|
-comments (C++ style, can start anywhere) or / * * / comments (C style,
|
|
|
-can span multiple lines).
|
|
|
+The parser code contains the code definition and the Kea-dhcp6 updated
|
|
|
+to use that new parser. That parser is able to to load all examples
|
|
|
+from doc/example/kea6. It is also able to parser # comments (bash
|
|
|
+style, starting at the beginning or middle of the line), // comments
|
|
|
+(C++ style, can start anywhere) or / * * / comments (C style, can span
|
|
|
+multiple lines).
|
|
|
|
|
|
-This parser is currently used. See configure() method in kea_controller.cc.
|
|
|
+This parser is currently used in production code. See configure()
|
|
|
+method in kea_controller.cc.
|
|
|
|
|
|
There are several new unit-tests written, but the code mostly reuses existing
|
|
|
one to verify that existing functionality was not compromised. There are
|
|
|
@@ -310,21 +311,29 @@ check if it's a valid JSON syntax, but also check that the resulting structures
|
|
|
match expected syntax (if subnet6 are really an array, not a map, if
|
|
|
timers are expressed as integers, not as strings etc.).
|
|
|
|
|
|
-However, there are times when we need to parse a string as arbitrary JSON.
|
|
|
-For example, if we're in Dhcp6 and the config contains entries for DhcpDdns
|
|
|
-or Dhcp4. If we were to use naive approach, the lexer would go through
|
|
|
-that content and most likely find some tokens that are also used in Dhcp6.
|
|
|
-for example 'renew-timer' would be detected and the parser would complain
|
|
|
-that it was not expected. To avoid this problem, parser context was
|
|
|
-introduced. When the syntactic parser expects certain type of content,
|
|
|
-it calls @ref isc::dhcp::Parser6Context::enter() method to indicate what
|
|
|
-type of content is expected. For example, when Dhcp6 parser discovers
|
|
|
+However, there are times when we need to parse a string as arbitrary
|
|
|
+JSON. For example, if we're in Dhcp6 and the config contains entries
|
|
|
+for DhcpDdns or Dhcp4. If we were to use naive approach, the lexer
|
|
|
+would go through that content and most likely find some tokens that
|
|
|
+are also used in Dhcp6. for example 'renew-timer' would be detected
|
|
|
+and the parser would complain that it was not expected. To avoid this
|
|
|
+problem, syntactic context was introduced. When the syntactic parser
|
|
|
+expects certain type of content, it calls @ref
|
|
|
+isc::dhcp::Parser6Context::enter() method to indicate what type of
|
|
|
+content is expected. For example, when Dhcp6 parser discovers
|
|
|
uninteresting content like Dhcp4, it enters NO_KEYWORD mode. In this
|
|
|
mode, everything is parsed as generic maps, lists, integers, booleans
|
|
|
or strings. This results in generic JSON structures without any syntax
|
|
|
-checking. Of course a corresponding/balanced @ref
|
|
|
-isc::dhcp::Parser6Context::leave() call is required before leaving
|
|
|
-the context to come back to the previous context.
|
|
|
+checking. A corresponding/balanced @ref
|
|
|
+isc::dhcp::Parser6Context::leave() call is required before leaving the
|
|
|
+context to come back to the previous context.
|
|
|
+
|
|
|
+Entering a new syntactic context is useful in several ways. First, it allows
|
|
|
+the parser to avoid conflicts. Second, it allows the lexer to return different
|
|
|
+tokens depending on context (e.g. if "renew-timer" string is detected, the lexer
|
|
|
+will return STRING token if in JSON mode or RENEW_TIMER if in DHCP6
|
|
|
+mode). Finally, the syntactic context allows the error message to be more
|
|
|
+descriptive if the input string does not parse properly.
|
|
|
|
|
|
Details of the refactor of the classes derived from DhcpConfigParser are
|
|
|
documented in http://kea.isc.org/wiki/SimpleParser.
|
Tomek Mrugalski