Idea to have qmicli output "parseable" data

[Ed W]

Hi, I needed to access details of my modem via Elixir and I have a future requirement to do similar
things via Lua. However, it seems more than a small hurdle to get access to libqmi from any
scripting languages?

My first thought was to adapt qmicli, which largely does everything I need, but to patch the output
to be optionally JSON or similar. However, the coding style of qmicli, doesn't easily lend itself to
this kind of change. The issue is that, at present, whilst many commands could be adapted, many
others generate bits of string data dynamically in response to nested conditionals, etc.

So, because it's a potentially pretty large change, how much interest is there to adapt the qmicli
app to instead of generating direct string output, to instead generate some kind of nested structure
(map), which will then either be kicked out as text (identical to present), but can also optionally
be converted to something hierarchical and parseable, such as json/xml/toml, etc?


In the meantime for my elixir library I took a stab at simply parsing the text which comes out of
the current qmicli utility. It's largely indented into a structure and so (largely), by counting
tabs at the beginning of the line one can fold it back into some kind of structure that makes it
easy to process in a given scripting language.

However, there isn't absolute consistency in the format of the output, for example, compare:

    /usr/bin/qmicli -p -d /dev/cdc-wdm0 --nas-get-serving-system

and most other commands, eg

    /usr/bin/qmicli -p -d /dev/cdc-wdm0 --nas-get-signal-strength


The output from nas-get-serving-system is all shown with an extra level of tab indents (ie indent
level starts at 1), whereas most other commands are left aligned, ie indent level of 0 starts at 0.

Another (minor) challenge is that errors/status messages are not completely homogeneous, eg a
general error in params causes output to stderr and I think a non zero return code(?), however,
status messages relating to a command where the params are ok shows all results on stdout, with the
qmi data "mixed in" with the status messages from the utility. eg the first line of most messages,
or the trailer if you add "--client-no-release-cid"

Another curiousity is the output if you call "--client-cid=xx" with an invalid cid, this spits out
an error immediately, but the app doesn't exit for another 10 seconds with a further timeout
message. (from memory one to stdout, one to stderr)

So not withstanding all of this, I can do the following in my elixir app (which actually works quite
well for my needs):


    iex> Exqmi.qmicli(nil, "nas-get-serving-system", device: "/dev/cdc-wdm0")

    {:ok, "Successfully got serving system",
     %{
       "3GPP cell ID" => "283456",
       "3GPP daylight saving time adjustment" => {"1", "hours"},
       "3GPP location area code" => "65534",
       "CS" => "attached",
       "Current PLMN" => %{
         "Description" => "voda UK",
         "MCC" => "234",
         "MNC" => "15"
       },
       "Data service capabilities" => %{"0" => "lte", "_value" => "1"},
       "Detailed status" => %{
         "Capability" => "cs-ps",
         "Forbidden" => "no",
         "HDR Hybrid" => "no",
         "HDR Status" => "none",
         "Status" => "available"
       },
       "Full operator code info" => %{
         "MCC" => "234",
         "MNC" => "15",
         "MNC with PCS digit" => "no"
       },
       "LTE tracking area code" => "12345",
       "PS" => "attached",
       "Radio interfaces" => %{"0" => "lte", "_value" => "1"},
       "Registration state" => "registered",
       "Roaming indicators" => %{"0" => {"off", "(lte)"}, "_value" => "1"},
       "Roaming status" => "off",
       "Selected network" => "3gpp"
     }}


Basically the output is really close to being parseable without too much trouble. However, it feels
like a change in how the messages are generated in the first instance, could lead naturally to a
final output step that is capable of spitting out the result in a variety of forms. I'm not really
familiar with what tools we already have in glib, but perhaps it already has a structure (map?) that
we can put the messages into at construction time? ie I'm looking for the smallest change possible,
ideally something that can be automated given the amount of code that would be touched.

Any thoughts?


Ed W

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