<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 27/07/2021 14:17, Aleksander Morgado wrote: </div> <blockquote type="cite" cite="mid:CAAP7uc+=Zb9oweKJPwFSH13U=Kiz6U+sGZ-WMPd-mSjsMgZCiA@mail.gmail.com"> <pre class="moz-quote-pre" wrap="">Hey Jack and Ed, </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I have had this exact same question before. There is a MR <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/190">https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/190</a> that does exactly this. I have not made contributions to it so I don't want to take credit for it but I'm quite excited for when it is merged! </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Yes, I was going to point to that merge request. The auto-generation of JSON data for all data types is already available in that MR, but it still requires to go over all qmicli commands one by one adding a few lines to be able to print the JSON output. The MR contains support for just a few commands, the ones that the company that hired me to do that needed :) </pre> </blockquote> Thanks, this looks excellent! I wonder if the error reporting is worth merging separately? This was one of the oddities I had noticed that slightly complicated parsing However, as you have done some work, can I ask what your opinion is on some of the more complicated outputs? I don't have the code open, but several commands seemed to be doing significant manipulation of the output structure while printing it. These seemed to be the complex ones to have to convert really? Also, inserting lots of " if (qmicli_output_json ()) {" feels like a lot of typing...? Can we do better? I wonder if we can't go a further up and consider the individual commands to be knocking some output map alike structure into shape, then the output is just a structure we either output as text, or output as json as we prefer? I wonder at the moment if the JSON and test outputs would be so similar? How did you propose to handle the cases where there is both a value for a key and a sub value? For example in "--nas-get-serving-system" we have Radio interfaces: '1' [0]: 'lte' What I did was to store the '1" in a "_value" key under the "Radio interfaces" key I also provided some heuristics to parse keys like: 3GPP daylight saving time adjustment: '1' hours into ['1', 'hours'] However, there is a certain lack of consistency here in the output, so it only "mostly works" Anyway, exciting that there is interest. I think it's worth kicking around the exact steps as it's quite a lot of typing to get this done. Any observations? Ed W </body> </html>