Hi,

Just a quick bump, wondering if someone could take a look at the diff,
conscious there appears to have been a lot going on recently!

I want to do some more detailed work on the json output, but would
ideally get this first iteration in first.

Richard

On Sat, May 23, 2020 at 9:28 AM Richard Chivers <r.chiv...@zengenti.com> wrote:
>
> Hi,
>
> I have attached the first iteration of the ospf json support. Sorry
> about the large commit,
> but it had to come in one go, if we didn't want a broken implementation.
>
> I will go back and update output.c and output_json.c to remove the detail flag
> and instead pass through the cli parse_result as is done in bgpctl -j sh rib,
> but thought it made sense to get the main commit out of the way and
> then circle back
> to these tweaks next week.
>
> In general I think there should be a consideration over how times are output.
>
> At present this diff outputs time using the pretty standard approach
> used in ospfctl all along,
> which is also what bgpctl -j sh rib does.
>
> I question whether for durations and uptime we should perhaps
> introduce something like
>
> uptime_seconds: 30
> uptime_seconds: null
>
> as well as or rather than:
>
> uptime: "6d06h31m"
> uptime: "00:00:00"
>
> I'm not sure if the above is a standard format (6d06h31m) that can be parsed
> easily in many languages, which is part of what json support adds to the mix,
> if it is then it is the best of both worlds already!
>
> I can take a dig into this, but i'm sure someone will know off hand,
> if so what is the RFC or equiv?
>
> The only aspects I have not tested are:
>
> ospfctl -j show database summary
> ospfctl -j show database opaque
>
> These have no results in my configuration.
>
> I do question wheter ospfctl -j show database summary just needs removing?
> I will perhaps have a dig into ospfd and see what generates the relevant imsg.

Reply via email to