Hi, I have done some work over the last few days to implement json support into ospfctl following the work done recently in bgpctl.
I have some queries, hoping to get some help with. The change involves a refactor of ospfctl, but reuses the recent json.c written by Claudio, that is in the usr.sbin/bgpctl directory. At present no changes have been required at all. What is the best approach here, should/could this be centralised somewhere? In some cases there is room for change, for example ospfctl sh rib & ospfctl sh rib detail. In my view here, it makes sense to have a full list returned rather than splitting json into multiple lists of Router, Network and External. I looked for inspiration in the bgpctl, but couldn't find a similar pattern. The reason for a single list is that if consuming the json, I expect you will not want code that has to iterate over three separate arrays. Just looking for some feedback really. The original split made sense for screen use, just not so sure about machine readability. This issue also applies to ospfctl sh data, which returns 3 lists. When I am finished, should I just post the diff on here? Just conscious it is quite a big refactor, albeit much of the code is reused just moved into output.c as was done for bgpctl. I am testing each call individually against a set of openbsd 6.6 boxes we have running, which is great for ospfd. What is the normal practise for ospf6, is there a script run to replicate code changes or is it just a case of making very similar changes line by line? Just looking for the general thinking and approach I guess. I don't currently have ospf6 set-up so that would be some overhead. Happy to configure it though if needed/expected. Finally what was the driver under bgpctl for the json output, ours is for reading metrics to populate telemetry, just interested as the purpose other people have. Having this context will help in micro decisions when implementing the json structure. As a final thought is this something that is actually wanted generally, I assumed it was as bgpctl has gone/is going in that direction, but just don't want to assume. Cheers Rich
