1 files changed, 95 insertions, 0 deletions
diff --git a/docs/reference/api/ModemManager-overview.xml b/docs/reference/api/ModemManager-overview.xml
new file mode 100644
index 00000000..95764795
--- /dev/null
+++ b/docs/reference/api/ModemManager-overview.xml
@@ -0,0 +1,95 @@
+<?xml version="1.0"?>
+<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
+]>
+<part id="ref-overview">
+  <title>ModemManager Overview</title>
+
+  <chapter id="ref-overview-introduction">
+    <title>Introduction</title>
+    <para>
+      ModemManager provides a unified high level API for communicating with
+      (mobile broadband) modems. While the basic commands are standardized,
+      the more advanced operations (like signal quality monitoring while
+      connected) varies a lot.
+    </para>
+    <formalpara>
+      <title>Using</title>
+      <para>
+        ModemManager is a system daemon and is not meant to be used directly from
+        the command line. However, a command line client (mmcli) is provided, which
+        may be used to test the different functionality provided during plugin
+        development.
+      </para>
+    </formalpara>
+    <formalpara>
+      <title>Implementation</title>
+      <para>
+        ModemManager is a DBus system bus activated service (meaning it's started
+        automatically when a request arrives). It is written in C. The devices are
+        queried from udev and automatically updated based on hardware events. There are
+        DBus-interface specific GInterfaces, which should be implemented by any device
+        specific implementation. There is a generic MMBroadbandModem implementation that
+        provides a generic implementation of the most common operations in both GSM and
+        CDMA modems.
+      </para>
+    </formalpara>
+    <formalpara>
+      <title>Plugins</title>
+      <para>
+        Plugins are loaded on startup, and must implement the MMPlugin interface. It
+        consists of a couple of methods which tell the daemon whether the plugin
+        supports a port and to create custom modem implementations. It most likely
+        makes sense to derive custom modem implementations from one of the generic
+        classes and just add (or override) operations which are not standard. Writing
+        new plugins is highly encouraged!
+      </para>
+    </formalpara>
+  </chapter>
+
+  <chapter id="ref-overview-states">
+    <title>State machine</title>
+    <para>
+      ModemManager implements support for each Modem by controlling their
+      behaviour following the steps given in the following state machine.
+    </para>
+    <figure id="mm-modemmanager-states">
+      <title>ModemManager states</title>
+      <graphic fileref="../ModemManager-states.png" format="PNG"></graphic>
+    </figure>
+    <para>
+      The state machine of a modem can be summarized in 5 main sequences:
+      initialization, enabling, connection, disconnection and disabling.
+    </para>
+    <section>
+      <title>Initialization</title>
+      <para>
+        <!-- TODO -->
+      </para>
+    </section>
+    <section>
+      <title>Enabling</title>
+      <para>
+        <!-- TODO -->
+      </para>
+    </section>
+    <section>
+      <title>Connection</title>
+      <para>
+        <!-- TODO -->
+      </para>
+    </section>
+    <section>
+      <title>Disconnection</title>
+      <para>
+        <!-- TODO -->
+      </para>
+    </section>
+    <section>
+      <title>Disabling</title>
+      <para>
+        <!-- TODO -->
+      </para>
+    </section>
+  </chapter>
+</part>