<div dir="ltr"><div>Hi everybody,</div><div><br></div><div>This thread has awaken some evil thoughts I have had since long ago. I know this might be forbidden here, but still, I could not sleep well until I did it. Please don't beat me for that. :)</div><div>So here is the patch (applies to "thread-next" branch). It is definitely ugly, ineffective, untested, requires a lot of polishing, etc. It was mostly created as a proof of concept for now. It seems to be working at least on my simple tests with device, kernel, pipe, bgp protocols. With it you can send "json protocols" command and get a dump of protocols in JSON. It also adds "-q" option to cli to hide the "BIRD ..." header, so you can do things like:</div><div><br></div><div>$ ./birdc -q "json protocols" | jq '.protocols.bgp1.Channels.ipv4["Gateway mode"]'<br>"recursive"<br></div><div><br></div><div>I know we all long for a great API to come. But unitl that we sill have to parse the text cli output. So why not to parse for example JSON isntead? :) It is safer to extend and not to break compatibility with text parsers. This and other benefits are mostly well-known. Of course it is ugly piece of code added to the codebase, that needs to be maintained, etc. All the minuses has also been well described here already. Anyway, I do not expect it to be included upstream, just had some strange need to do this coding exercise. :) On the other hand if it looks appealing, I can polish/improve it if needed. Also "routes" variant could be added.</div><div>Any feedback is welcome! And I can give more comments on the contents, of course.</div><div><br></div><div>PS. Also another idea has come to my mind. What BIRD team think about introducing a practice of adding experimental features, i.e. those that have no guarantee to remain compatible between versions, or to remain at all. It is often said that adding new features is a hard process because they need to be maintained, harden merges between versions, need thourough study right away because further redesign can break compatibility. So I think calling it experimental and giving yourself an opportunity to "undo" it, could break the tie and give some "sandbox" for the feature to mature or perish.</div><div><br></div><div>PPS. I'm not advocating my json patch with that idea. :)</div><div><br></div><div>Regards,</div><div>Alexander</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Sep 10, 2025 at 1:02 PM Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com">fischerdouglas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><a href="https://gitlab.nic.cz/labs/uytc/-/blob/dirty/examples/00_leaf/expected.output" target="_blank">https://gitlab.nic.cz/labs/uytc/-/blob/dirty/examples/00_leaf/expected.output</a><br>😍<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 9 de set. de 2025 às 20:56, Maria Matejka via Bird-users <<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><u></u>


  
  
  
  

<div>
<p>Hola!</p>
<blockquote>
<blockquote>
<p>With that, there is some internal tooling work on the way (because
people around Netconf didn’t bother to think about performance, let
aside maintainability) and as soon we have this, at least an
experimental API is gonna be there quite fast.</p>
<p>The actual tooling is UYTC YANG To Code which should enable you
to</p>
</blockquote>
</blockquote>
<blockquote>
<p>Doing google (not the best for this atm) on “UYTC YANG To Code”
returns a I mistyped this it must be UTC YANG … the rest of the returned
data is utterly garbage , Is there a url for this tooling you speak of
?</p>
</blockquote>
<p>Well, there is just a git repo with pieces of code in a very
being-worked-on state. Not much to actually see for now, there are just
several branches of dirty python code for now.</p>
<p><a href="https://gitlab.nic.cz/labs/uytc/" target="_blank">https://gitlab.nic.cz/labs/uytc/</a></p>
<p>Yet, this thing is, in the end, going to have a module for creating C
code. But first we have to digest through all the funky RFCs around
YANG, CBOR and whatever else blocks us, including drafting some new
stuff, to make everything actually fly the reasonable way.</p>
<p>Once, Donald E. Knuth said: »So, I just have this philosophy that
there will be always some people who are more interested in quality than
others, and I wanted to make TeX good for them.« (pg. 349
<a href="https://www.tug.org/TUGboat/tb17-4/tb53knun.pdf" target="_blank">https://www.tug.org/TUGboat/tb17-4/tb53knun.pdf</a>)</p>
<p>And we wanna make this right, and minimize the oversights which would
be too late to fix later. The original architecture of BIRD was good for
20 years, saved us a lot of hair, and many parts of it are actually
still there.</p>
<p>Maria</p>
<p>–<br>
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</div>

</div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>
</blockquote></div>