On Thu, Apr 13, 2017 at 6:09 PM, Dan Williams <[email protected]> wrote: >> > This thread turns out to be relevant to the latest in my battle >> > with Cinterion modules. Their EHS5 doesn't support AT^SPIC, but it >> > turns out it does support the CSIM commands used by the telit >> > plugin - https://developer.gemalto.com/tutorial/how-query-pin-count >> > er-ehsx >> >> >> As a follow-on musing, does MM have mechanisms (or examples) for >> cascaded fallback procedures - i.e. "Try to do this [set of >> operations] using Method A, and if an an 'un-supported' error comes >> back, then try Method B".....? >> Is it just (ha!) a case of expanding out the 'context step' code >> flow? > > Right, if you have [set of operations A] and then [set of operations B] > and need to jump to B if some part of A fails, that's usually done > through the "context step" pattern that you've seen. That pattern > keeps all the flow decision logic in one place, rather than having it > sprinkled around a bunch of different functions in the file.
If we find the CSIM-based method to be generic enough, we could add it in the MMBroadbandModem object directly, and have subclasses that want to use it just skip providing a custom method themselves (e.g. what Telit would do) or use the "parent" implementation as fallback if the plugin-specific one (e.g. AT^SPIC based in Cinterion) isn't supported. In the latter case, though, the decision logic step would also be required in e.g. the "context step" pattern, just calling the parent implementation instead of a different custom one. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
