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