Idea to have qmicli output "parseable" data

[Ed W]

Hi


>> I wonder if the error reporting is worth merging separately? This was one of the oddities I had noticed that slightly complicated parsing
>>
> Error reports are given in TLVs as any other TLV in the response
> message. I think that would be the best thing to do also in the JSON
> output, so that the parsers can expect this TLV to exist ALWAYS in all
> response messages:
>
>   "result": {
>     "error-status": "0",
>     "error-code": "0"
>   },


Yes please!

Also remember that in some circumstances there is some "noise", which is kinda error, kinda status,
kinda data. I'm thinking about when you start a data connection and/or keep a CID open

Perhaps we can get that into the result section and have a separate "data" section?


> For some of the messages, it's true that qmicli also does some magic
> here and there, but I believe printing the raw contents of the
> response in JSON isn't a bad initial approach.


I'm indifferent, but if you are asking me, I would say lets try and have the JSON output be
identical to the text output, ie it's just a formatting concern?


>> 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?
> That's basically what we did in ModemManager, yes, see
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/master/cli/mmcli-output.c
> Even the "human pretty output" is generated by the output engine.


^This! Lets do this!

I waiting, but not hearing cries that we shouldn't change the output of qmicli too much..? I wonder
if someone has a vote that we fork qmicli into a sort of new utility, deprecate the old one and
steal something like the mmcli formatter here to bolt onto the qmicli base?



>> 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
>>
> Really, I don't remember what was done for every type. What I did was
> to improve the qmi-codegen output to also support generating the JSON
> output, it's very much the same as the printable message outputs we
> have when traces are enabled in libqmi, the very same idea. Arrays are
> converted into JSON arrays, complex types are converted into JSON
> structs, and so on.
>
>> I also provided some heuristics to parse keys like:
>>
>>     3GPP daylight saving time adjustment: '1' hours
>>
>> into ['1', 'hours']
>>
> That would be too much IMO. The original idea was that the JSON output
> in libqmi should print raw values as received from the modem. But
> then, a lot of fields in QMI messages have "additional" formatting
> required, as e.g. with the signal quality values in several messages.
> For example, the SNR for LTE in "NAS Get Signal Info" is not given in
> dB directly, you need to divide the given value by 10 in order to get
> the dBs. What should the JSON output report in this case? the original
> value or the one already processed to get dBs? It's tricky, and it's
> really a lot of work, but it may be a good idea to give the processed
> values also in the JSON output, for simplicity (i.e. we do it once in
> libqmi, instead of N times by N different users). My original
> implementation would need to be changed a lot to support that I'm
> afraid.


I'm not sure what is feasible within the constraints of the original data type? In my head we:

- get the original data

- massage it for the benefit of sensible consumption

- lightly format it as part of the output


So I am ignorant of the details, but I would be wondering if we could tag values with a "type", such
that a generic output formatter could do some scaling and apply a suffix (eg -23dB) in the case of a
textual format, but perhaps do something slightly different in the case of the json/xml output, eg
["-23", "dB"]

What options are simple in this space?

I think the goal would be a small number of consistent modifications which add value, rather than
the current situation of micro massaging specific API outputs (possibly in an inconsistent manner?).
Does this sort of thing exist in mmcli?

How many people are going to moan if qmicli has a dramatic shakeup in the normal textual output? How
would such a theoretical shakeup be best handled? (Suggestion above to create a new utility to give
people time to migrate?)

I do think there would be quite a lot of value in going through a broadly similar output process for
plain text and json?

As you say, there is a lot of typing if we don't get this planned out in advance - lets get this right

Further discussion appreciated?

Ed W