[kea-dev] Converting configuration back to JSON (unparsing)

[Francis Dupont]

Tomek Mrugalski writes:
> One of the features of upcoming 1.2 release will be the ability to
> retrieve (get-config command) and store (write-config command) current
> configuration. This problem is currently scoped to DHCPv4 and DHCPv6,
> but the solution should also cover D2 and CA if possible.

=> if D2 and CA uses Cfg like classes to store configurations
there should be no problem to extend the solution to them.
 BTW for DHCPv4 and DHCPv6 configurations were at the right place
(Cfg like classes under SrvConfig class (which is itself Cfg like)
at the exception of a few things directly in the config manager
and hook libraries in the parser itself).

> I discussed this with Thomas and we're leaning towards the unparse
> method to return C. The actual method should have the following interface:
> 
> ElementPtr toElement() const;

=> the only open point is the method name. I use(d) unparse,
toElement is a bit better. For the abstract class ToElement seems
good, now I hesitate between cfg_to_element.h or to_element.h
(there are 18 header files using it, 4 only with a name which
don't begin by cfg_ so IMHO cfg_to_element.h is better).

> Also, usage of "parser" and "parse" words is overloaded in Kea project.
> We use the same word to describe text to Element tree conversion (done
> with bison) and also to describe Element tree to configuration
> structures (done with SimpleParser derivatives). As such, unparse would
> be confusing whether it undoes the second or both steps. Therefore
> calling the method toElement() seems better.

=> unparse is ugly so it is good only inside comments...

> Finally, converting from Element to text is trivial, because there are
> Element::str() and << operators defined.

=> there is a planned pretty printer too.

> Any thoughts? Comments? If I don't hear any objections in couple days,
> the 1205 ticket will be closed and we'll start with the implementation.

=> there is already a trac1205 branch so we should recycle the ticket.
And the implementation ticket #5114 will be big (6k lines for the diff)
so I strongly suggest to not put everything in it.

Thanks

Francis Dupont <fdupont at isc.org>