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

Thomas Markwalder tmark at isc.org
Thu Feb 23 19:58:31 UTC 2017


On 2/23/17 2:53 PM, Tomek Mrugalski wrote:
> 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.
>
>>> 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.).
That works also.

>>> 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.
>
> 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.

Good point, coding before design will get you everytime ;)
>> 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. Sure, it would be nice if the JSON returned was nicely indented,
> but that is not something that is really needed. 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. That's sad, but
> true. We have very limited manpower right now and we need to be careful,
> which tickets we spend time on.
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev




More information about the kea-dev mailing list