<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 27/07/2021 21:14, Aleksander Morgado wrote: </div> <blockquote type="cite" cite="mid:CAAP7ucJy+=0z1K0OpMJS_YWCBYyT90YFO5_wNK14vNEXpL9_3Q@mail.gmail.com"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">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? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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... </pre> </blockquote> OK, so mad idea to kick around: Lots of the code looks something like this: <pre class="code highlight" lang="c"> 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", </pre> 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 </body> </html>