From 480fe4b8087ea323f46e8abee6a71323746b6693 Mon Sep 17 00:00:00 2001 From: Aleksander Morgado Date: Fri, 2 Mar 2012 13:06:42 +0100 Subject: docs: new section about plugin-specific modems --- docs/reference/api/ModemManager-overview.xml | 51 +++++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-) (limited to 'docs/reference/api/ModemManager-overview.xml') diff --git a/docs/reference/api/ModemManager-overview.xml b/docs/reference/api/ModemManager-overview.xml index fec56e55..e7305370 100644 --- a/docs/reference/api/ModemManager-overview.xml +++ b/docs/reference/api/ModemManager-overview.xml @@ -433,7 +433,7 @@ mm_plugin_create (void) - Modem interface initialization + Modem interface initialization The Modem interface provides common actions and information available in the majority of the modems @@ -639,6 +639,55 @@ mm_plugin_create (void) + + + Plugin-specific Modems + + ModemManager plugins exist in order to handle all non-standard vendor-specific behaviour + that needs to get supported. + + + Plugins will provide their own Modem object implementations, usually subclassing the + generic MMBroadbandModem object. As previously explained, this + object implements every interface that may be exported by the Modem object in DBus; and + then, depending on the per-interface support checks, the interface will end up being + really exported or not. + + + Each interface defines every step to be run during the initialization, enabling or + disabling sequences. Then, the object implementing the interface may or may not provide + the implementation of such step. By default, the generic + MMBroadbandModem object implements already most of the steps + in the interfaces providing common features: + +
+ Modem interface initialization sequence + +
+ + Vendor-specific subclasses of MMBroadbandModem are then able to + either provide their own implementation of a given step (in the image below, a custom + implementation for capabilities checking); or even completely disable the step if they + know that there is no way to run it (in the image below, revision string loading is + removed). + +
+ Modem interface initialization sequence subclassed + +
+ + These subclass-able steps are all implemented as standard GIO asynchronous functions, + so subclassing a step involves implementing both the async method which receives the + input arguments to the action and the corresponding _finish() method + which provides the results of the action once the operation is ready. + + + It is worth noting that these steps and the asynchronous methods implementing them + don't assume that an AT port will be used to implement the real action. This means + that any other kind of port may be really used (e.g. QCDM or QMI) in the implementation, + or even that a static reply can be returned (e.g. Iridium modems will always report + "Iridium" as current OperatorName). + -- cgit v1.2.3-70-g09d2