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.
