> In your case with the Telit modem and QSS:3; if we decide that it's > not worth waiting for QSS:3 because it takes too long and for our > purposes we can use it much earlier, then we could do the per-step > retries on SIM busy errors.
The problem here is that, according to my tests, even if we try to get this info earlier, polling at some intervals, we end up waiting the same amount of time. > The idea of updating in the background and letting the remaining logic > to flow is a bit anarchic, as the user of the API cannot know when the > property values are done populated. Yes, you're right, I wasn't thinking about that. I've got the idea of dropping this change, actually. As I said, the goal was to have some logic to recover several situations of "sim busy", but I couldn't make a scalable solution that isn't tailored strictly around this specific case and, at the end of the day, it doesn't seem to provide a real improvement, specially if compared to the increased complexity. Finally, this issue affect only the SIMs of a specific vendor and the most important information (SIM and PUK) are always retrieved correctly.
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
