add some more docs

3 files changed, 213 insertions, 4 deletions

diff --git a/doc/xml/ck-design.xml b/doc/xml/ck-design.xml
index 26affba..d908822 100644
--- a/doc/xml/ck-design.xml
+++ b/doc/xml/ck-design.xml
@@ -1,5 +1,171 @@
 <chapter id="design">
   <title>Design</title>
 
+  <sect1>
+    <title>Session Lifecycle</title>
+    <para>
+The session leader process is responsible for asking
+ConsoleKit to open a new session.  In this respect, it is
+similar to the traditional POSIX user login accounting framework.
+In the typical case, the session leader is either an immediate descendant of
+a login manager or the login manager itself.  The leader makes a connection to the D-Bus system bus and asks ConsoleKit to open a session.  There are two methods available for opening a session: org.freedesktop.ConsoleKit.Manager.OpenSession() and org.freedesktop.ConsoleKit.Manager.OpenSessionWithParameters().
+    </para>
+    <para>
+If the operation succeeds, a secret cookie will be returned to the session leader.  The session leader should store this secret in the environment as XDG_SESSION_COOKIE so that it may be shared with its child processes.
+    </para>
+    <para>
+At this point the session will be registered with ConsoleKit and a particular
+set of information about the session will be stored along with it.
+    </para>
+    <para>
+ConsoleKit will decide, based on the information associated with the session, what Seat the session will be added to.
+    </para>
+    <para>
+It will also be determined, based on the same set of information, whether the Session will control the hardware associated with the Seat.  In other words, whether the Session will be active for the Seat it is attached to.  The exact mechanism for this determination depends on the type of Seat and the capabilities of the host system.
+    </para>
+    <para>
+The Session will remain open until the Session Leader disconnects from the D-Bus system bus or calls org.freedesktop.ConsoleKit.Manager.CloseSession().  The session will be removed from its Seat, and deregistered.
+    </para>
+  </sect1>
+
+  <sect1>
+    <title>Expected Usage</title>
+    <para>Use of this service will usually follow one of the following patterns:</para>
+
+    <sect2>
+    <title>Text Login Manager</title>
+      <para>This pattern operates as the Session Leader for a new Session.  This pattern needs:
+      </para>
+      <orderedlist>
+        <listitem>
+        To open a new Session.
+        </listitem>
+        <listitem>
+        To set properties for the Session.
+        </listitem>
+        <listitem>
+        To maintain a connection to the D-Bus system bus.
+        </listitem>
+        <listitem>
+        To close the Session at logout.
+        </listitem>
+      </orderedlist>
+    </sect2>
+
+    <sect2>
+    <title>Graphical Login Manager</title>
+      <para>In addition to the requirements for the Text Graphical Login Manager, this pattern is typically use to show information about currently open sessions and therefore needs:
+      </para>
+      <orderedlist>
+        <listitem>
+        To determine which Seat it is running on.
+        </listitem>
+        <listitem>
+        A list of all sessions on the current Seat.
+        </listitem>
+        <listitem>
+        To know which session is active for the current Seat.
+        </listitem>
+        <listitem>
+        To know when the session active state changes.
+        </listitem>
+        <listitem>
+        To know when sessions are added or removed.
+        </listitem>
+        <listitem>
+        Access to the metadata for any open Session.
+        </listitem>
+      </orderedlist>
+    </sect2>
+
+    <sect2>
+    <title>System Daemon</title>
+      <para>This is generally a daemon process running outside of a user session as a special user.  This pattern needs:
+      </para>
+      <orderedlist>
+        <listitem>
+        To know if any user sessions are open.
+        </listitem>
+        <listitem>
+        To know if the system is currently being used.
+        </listitem>
+      </orderedlist>
+    </sect2>
+
+    <sect2>
+    <title>Hardware Abstraction Layer</title>
+      <para>This is a special case of System Daemon that provides catalogs and control mechanisms for hardware devices.  In addition to the requirements of System Daemon, this pattern needs:
+      </para>
+      <orderedlist>
+        <listitem>
+        To determine what hardware is associated with a Seat.
+        </listitem>
+        <listitem>
+        To determine what Session is active and inactive on a particular Seat.
+        </listitem>
+        <listitem>
+        To know when the session active state changes.
+        </listitem>
+        <listitem>
+        To determine what Session a process belongs to.
+        </listitem>
+      </orderedlist>
+    </sect2>
+
+    <sect2>
+    <title>Fast User Switching Agent</title>
+      <para>This is usually a kind of delegate for the Graphical Login Manager and provides a shortcut to the similar functionality.  It is usually in form of a tool available in the user session that allows one to quickly switch to another user session.  This pattern needs:
+      </para>
+      <orderedlist>
+        <listitem>
+        To determine which session it is running in.
+        </listitem>
+        <listitem>
+        A list of all sessions on the current Seat.
+        </listitem>
+        <listitem>
+        Which session is active for the current Seat.
+        </listitem>
+        <listitem>
+        To know when the session active state changes.
+        </listitem>
+        <listitem>
+        Access to the metadata for any open Session.
+        </listitem>
+        <listitem>
+        To know when sessions are added or removed.
+        </listitem>
+      </orderedlist>
+    </sect2>
+
+    <sect2>
+    <title>Session Daemon (aka Policy Agent)</title>
+      <para>This is typically a daemon running in a user session that acts on policy only when the session is active.  This pattern needs:
+      </para>
+      <orderedlist>
+        <listitem>
+        To determine which session it is running in.
+        </listitem>
+        <listitem>
+        To know when the session active state changes.
+        </listitem>
+      </orderedlist>
+    </sect2>
+
+    <sect2>
+    <title>Session Application</title>
+      <para>This is typically an application running in a user session that may alter its behavior when the session active state changes.  This pattern needs:
+      </para>
+      <orderedlist>
+        <listitem>
+        To determine which session it is running in.
+        </listitem>
+        <listitem>
+        To know when the session active state changes.
+        </listitem>
+      </orderedlist>
+    </sect2>
+
+  </sect1>
 
 </chapter>
diff --git a/doc/xml/ck-introduction.xml b/doc/xml/ck-introduction.xml
index a2fc54a..b38adf5 100644
--- a/doc/xml/ck-introduction.xml
+++ b/doc/xml/ck-introduction.xml
@@ -14,12 +14,14 @@
   <sect1>
     <title>Defining the Problem</title>
     <para>
+    To be written.
     </para>
   </sect1>
 
   <sect1>
     <title>Relevant art</title>
     <para>
+    To be written.
     </para>
   </sect1>
 
diff --git a/doc/xml/ck-terms.xml b/doc/xml/ck-terms.xml
index 781e503..9b582da 100644
--- a/doc/xml/ck-terms.xml
+++ b/doc/xml/ck-terms.xml
@@ -4,22 +4,63 @@
   <sect1>
     <title>Session</title>
     <para>
-      ConsoleKit is a framework for keeping track of the various
-      users, sessions, and seats present on a system.  It
-      provides a mechanism for software to react to changes of any of
-      these items or of any of the metadata associated with them.
+A session is a collection of all processes that share knowledge of a
+secret.  In the typical (or ideal) case, these processes all originate
+from a single common ancestor.
+    </para>
+    <para>
+As an implementation detail, for now, this secret should be stored in
+the process environment by the session leader under the name
+XDG_SESSION_COOKIE.  When and if we are able to take advantage of a
+mechanism in the underlying system to store session registration
+information - we will.  However, such a mechanism is not known at the
+present time.
+    </para>
+    <para>
+Using an environment variable does have certain advantages.  For one,
+it is quite easy for a process to opt-out of a Session by simply
+unsetting the XDG_SESSION_COOKIE variable.
+    </para>
+    <para>
+Limitations of using an environment variable implementation include
+not being able to strictly limit visibility of the secret to a particular
+process ancestry.  So, it is not possible to enforce session boundaries
+other than on a per-user basis.  For example, we don't yet have a way
+to prevent a process from moving between sessions owned by the same
+user.
     </para>
   </sect1>
 
   <sect1>
     <title>Session leader</title>
     <para>
+The session leader is the process that requests that a new session be
+opened.  It does this by connecting to the D-Bus system bus and using
+either org.freedesktop.ConsoleKit.Manager.OpenSession() or
+org.freedesktop.ConsoleKit.Manager.OpenSessionWithParameters().  The session
+that it registers will be remain open until the connection to the system
+bus is lost or it calls org.freedesktop.ConsoleKit.Manager.CloseSession().
+    </para>
+    <para>
+The session leader is the only process for which CloseSession() will
+be allowed.
     </para>
   </sect1>
 
   <sect1>
     <title>Seat</title>
     <para>
+A seat is a collection of sessions and a set of hardware (usually at
+least a keyboard and mouse).  Only one session may be active on a
+seat at a time.
+    </para>
+    <para>
+At the present time, all Sessions that are considered "local" to
+a system will be added the the first Seat and every other Session
+will be added to its own Seat.
+    </para>
+    <para>
+True, hardware, multi-seat capabilities will be added in a later release.
     </para>
   </sect1>