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

[Thomas Markwalder]

On 2/23/17 12:20 PM, Francis Dupont wrote:
> 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).
Yes, D2 has an object hierarchy constructed from Elements via
SimpleParsers.  It is contained
in D2CfgContext.

https://jenkins.isc.org/job/Kea_doc/doxygen/d6/d31/d2.html#d2ProcessDerivation

See the section labeled Configuration Management

>> 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).
The class is going to be named ToElement()?  Class names should be
nouns, typically.
Having it be ToElement::toElement() seems a bit off.
 
What about something more like Configurable which defines toElement()
method.
There may come a time when we want Configurable objects to do other things.
In that case, the include file would be configurable.h

>
>> 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>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev