Idea to have qmicli output "parseable" data

[Ed W]

On 27/07/2021 21:14, Aleksander Morgado wrote:
>> 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?
>>
> You know what scares me most? The amount of special things we may need
> to do with the different fields. The SNR division by 10 is just 1
> single example. There are more complex things that we would also need
> to do, because we're doing them already in the human output; e.g.
> calls to qmi_nas_read_string_from_plmn_encoded_array() where
> appropriate, different print operations based on the contents of a
> given field... The things that we could do are so many, that in my
> mind, the only way forward would be to not even attempt to do them as
> part of qmi-codegen, and instead think in the post-processing phase
> applicable to all output types. It's something that we'll need to do
> one by one for each qmicli action...


OK, so mad idea to kick around:

Lots of the code looks something like this:

if (domain_valid)
g_print ("\t\tDomain: '%s'\n", qmi_nas_network_service_domain_get_string (domain));
if (service_capability_valid)
g_print ("\t\tService capability: '%s'\n", qmi_nas_network_service_domain_get_string
(service_capability));
if (roaming_status_valid)
g_print ("\t\tRoaming status: '%s'\n", qmi_nas_roaming_status_get_string (roaming_status));
if (forbidden_valid)
g_print ("\t\tForbidden: '%s'\n", forbidden ? "yes" : "no");
if (lac_valid)
g_print ("\t\tLocation Area Code: '%" G_GUINT16_FORMAT"'\n", lac);
if (cid_valid)
g_print ("\t\tCell ID: '%u'\n", cid);
if (registration_reject_info_valid)
g_print ("\t\tRegistration reject: '%s' (%s)\n",


The motivation is to try and get from where we are with fairly automated changes.

So what about replacing the g_print function in these calls with something that pushes the attribute
into some structure that we build iteratively? "g_push_key"... Granted this is less neat than
constructing some structure to pass to the output formatter, but some iteratively generated output
would be easier to migrate to?

So the number of \t's tells us if we are still at the same level. If we go down a level then we push
the current content into the current key, if we go up a level we start a new key, and so on.


I am not sure this is the best way to design an API, however, I'm trying to come up with something
where we can convert the current code reasonably mechanically. This mechanism would allow us to keep
the existing text formatting code. I'm wondering if we couldn't then look at adding extra API
commands to give a little more intelligence to the output eg pushing arrays, noting that a given
value has a value and a type, etc?


Where would such an idea get us? Could someone try and pour some sauce on this?

Ed W


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20210802/d9ac6621/attachment.htm>