How other applications use the ports that occupied by MM

[Aleksander Morgado]

>
> Yeah, mixed feelings from me too. I guess before we do that, can we ask
> what commands people want to use? I'd rather it not be used a short
> circuit for stuff that could be fixed in MM or implemented fairly
> easily for a device. That's my only reservation, that having it may
> reduce the incentive to fix/enhance MM itself.

Speaking here as a user, I've been in the need of running AT commands
sometimes as well, e.g.:
 * To enable/disable istp traces in Intel-XMM based devices.
 * To query the status of totally unrelated things, e.g. audio profile
settings, for which we will probably never have MM APIs.
 * To query the status of routes configured inside the modem, e.g
AT+UIPROUTE in the TOBY-L4.
 * To query device-reported temperature, although for that I could
envision a "temperature" interface or something like that.
 * For module certification purposes, or e.g. to show the current
status of the modem to people who "speak the AT protocol" but who
don't necessarily understand how MM or mmcli work.

Sometimes I've also seen people running mmcli --command for things
that would break the MM flow, e.g. running CFUN=4 and CFUN=1 manually
via --command, and that really messes up all the MM logic indeed, but
that is honestly the same mess that could happen after running qmicli
set operation mode offline/reset manually.

As long as the user understands that the API should be exclusively for
"reading state", all should be good... "should".

-- 
Aleksander
https://aleksander.es