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

[Francis Dupont]

Tomek Mrugalski writes:
> W dniu 23.02.2017 o 20:36, Francis Dupont pisze:
> >> The class is going to be named ToElement()?
> > => CfgToElement but it is an abstract class so classes will derived
> > from it.
> Huh? I thought toElement will be a method that will be implemented in
> each existing class, so no extra classes needed at all.

=> abstract == the class defines the virtual toElement method as = 0
(i.e. it gives only the type).

> >> Having it be ToElement::toElement() seems a bit off.
> > 
> > => the only place you should get it is in a doxygen comment
> > (and remember it is an instance method).
> There should be no extra class. There should be CfgMgr::toElement() that
> creates map element, puts all parameters it stores and then call
> toElement() on all of its children (CfgOpionDef::toElement(),
> CfgSubnets4::toElement(), etc.).

=> s/CfgMgr/SrvConfig/ and it is not an extra class but an abstract class
(an abstract template in fact as a few derived classes require
extra parameters, e.g. address family).

> >> What about something more like Configurable which defines toElement()
> >> method.
> > => it is more Configured than Configurable but this does not catch
> > the fact the derived class must implement a toElement() method.
> > So ToElement seems a natural name.
> > 
> > I've just updated fdunparse private branch to these new names.
> > And BTW there is no ToElement::toElement found by grep (:-).
> That's the problem of implementing code before there's an agreement how
> the code should look like.

=> change a name is not an issue but to know if something can be
implemented and with what effort requires experiments.

> When we planned the work, it was decided on a meeting to use 1205 for
> mini-design (that's what we're doing right now) and #5114 for the actual
> implementation.

=> this is why there is a trac1205 branch and no trac5114.

> > PS: for pretty print I believe a function is better (and less intrusive)
> > than to extend an existing method. I'll take the corresponding ticket
> > and change the code (and use it to not write whole configs for unit tests
> > twice :-).
> If it wasn't clear from the meeting, we do not need pretty print right
> now.

=> I am an human being so I need pretty printing. As I kept the code
somewhere I just propose to include it. And I am sure it will be useful,
for instance when toElement does not what was expected str/toJSON becomes
unreadable very quickly.

> Sure, it would be nice if the JSON returned was nicely indented,
> but that is not something that is really needed.

=> it is not needed for the control/command channel, it is needed for us.

> We're short on time and we can't spend time on things that are nice
> to have, but not necessary.  Even if you write it, nobody would be
> able to review it.

=> it is already written and it will save time in debug...

> That's sad, but true. We have very limited manpower right now and we
> need to be careful, which tickets we spend time on.

=> it is my time...

Regards

Francis Dupont <fdupont at isc.org>