[RFC] Exposing profiles (provisioned contexts) in the API

[Aleksander Morgado]

Hey Giacinto,

>
> for Cinterion modems that support the profiles, there is a special
> command to read them (ATI61, no mbim equivalent, maybe qmi but I
> wouldn't know it; and an at^scfg? option to read the current one) as a
> list and would fit well with option 2.
> The second option would also sit better in the context of a get/set
> option, because clearly option 3 wouldn't set it globally, and option
> 1 would be just informative.
>
> For Cinterion modems, the profiles have been experimented with for a
> few years, so old modems restart when a new profile is selected (for
> example, the PLAS9-X).
> Also, for all Cinterion modems supporting profile selection, they are
> normally in automatic mode and the property is indeed read-only.  It
> becomes writeable by changing the flag automatic/manual.
>
> I don't know exactly how other manufacturers work, but there are
> chances that it is implemented in a similar way, because the profiles
> were introduced by the chipset manufactures (initially) to deal with
> the various VoLTE flavours.
>

I believe we're not talking about the same thing, maybe we chose the
"profile" name poorly. The suggestion to manage the profiles in the
merge request is to be able to manage the settings for the PDP
contexts / EPS bearers stored in the modem. E.g. when you run
AT+CGDCONT? you get the list of contexts/bearers settings reported by
the module, that is what we would call "profiles" in the API. I don't
think this is what you were referring to, right? Maybe we should
choose a different name to avoid confusions.

Also, I can see this new API kind of collides with the concept of
"bearers" in our current API. Maybe we could instead update the
current Bearers management so that the listed context/bearer settings
are exposed as separate bearer objects right away (equivalent to the
option #3 in my original email). This was originally the idea back
when the API was written I think, which is why we have separate
"MaxBearers" and "MaxActiveBearers" properties. In the current MM
codebase, the Bearers objects are created only during a connection
attempt or when the initial EPS bearer status can be retrieved, it
would be a matter of changing that.

-- 
Aleksander
https://aleksander.es