Hi Aleksander, all, 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. Best Regards, Giacinto On Tue, Jan 12, 2021 at 11:30 AM Aleksander Morgado <aleksan...@aleksander.es> wrote: > > Hey all, > > Eric wrote an initial draft of the API to expose profiles (provisioned > contexts) in DBus here: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/179 > > The initial implementation he wrote relies on a read-only "Profiles" > property exposed in the 3GPP interface, with signature "aa{sv}" (an > array of dictionaries). > > A second option would be to have a new ListProfiles() method instead > of a read-only property, which is e.g. equivalent to what we already > have for the list of available firmwares installed in the > Firmware.List() method. > > A third option would be to promote the profiles to actual DBus objects > exported (as with SMS, Call, SIM...). This is maybe too much? > > For some context, these profiles could be loaded initially on modem > initialization, but they can also be asynchronously updated by the > modem itself (and could be reported to us via indications, as e.g. in > MBIM), or manually updated by us with the new methods we would add. My > only concern in this logic is that there may be some protocols where > these profiles are updated in the modem and not notified to us > actively via indications. In this case, I don't think how options > 1(the property) or 3 (the per-profile objects) would fit correctly, we > would end up not reporting up-to-date info. Only option 2 (the > explicit ListProfiles() method) would make sure that whenever the user > needs the list, this list is up to date (as we would list the profiles > at that exact time). > > What do you all think? > > -- > Aleksander > https://aleksander.es > _______________________________________________ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel