On 2020/05/17 12:02, Claudio Jeker wrote: > On Sun, May 17, 2020 at 11:51:33AM +0200, Denis Fondras wrote: > > > This implements a way to add a limit for bgpctl show rib output. > > > When a limit is set then the output will include a token (at the end) > > > that can be used to get the next batch of output. These two things allow > > > to build a frontend that puts the output onto multiple pages. > > > Both regular output and JSON output include the token. > > > > > > > I am not comfortable with this. It seems out of the scope of bgpctl. > > I would prefer to keep it simple / follow the unix way, aka pipe the output > > to > > another tool to paginate the output. > > In your example you use a temp file, why not work on this file to manage the > > limit / page display ? > > The idea is to use this for looking glass software. Currently bgplg will > a) load the bgpd excessivly when 'bgpctl show rib' is requested
This is quite a problem if you have public access to bgplg. It does feel a bit of a non-unixy approach but it's simple and fits nicely with the existing infrastructure and how it will actually be used (in particular it doesn't need a persistent connection to bgpd). I haven't read the diff thoroughly but I agree with the idea. > b) the output is too long for the user > c) if used with JSON the array will blow up some systems because there are > just too many objects in the output. > > This is a place where unix tools don't work well. You also don't want to > use head and tail to build a poor man paging system since it will not do a > fast lookup of the offset but instead walk over the table over and over > again. Also most of this is for a webservice using the JSON export.
