From ce1f72922f81fa83d2531adc93d3b733ec475f59 Mon Sep 17 00:00:00 2001
From: Federico Mena Quintero <federico@helixcode.com>
Date: Thu, 30 Nov 2000 02:43:57 +0000
Subject: Finished the calendar architecture chapter.

2000-11-29  Federico Mena Quintero  <federico@helixcode.com>

	* calendar/architecture.sgml: Finished the calendar architecture
	chapter.

svn path=/trunk/; revision=6729
---
 help/devel/calendar/architecture.sgml | 74 +++++++++++++++++++++++++++++++++--
 1 file changed, 71 insertions(+), 3 deletions(-)

(limited to 'help/devel/calendar/architecture.sgml')

diff --git a/help/devel/calendar/architecture.sgml b/help/devel/calendar/architecture.sgml
index f121144d29..d261f0a7f4 100644
--- a/help/devel/calendar/architecture.sgml
+++ b/help/devel/calendar/architecture.sgml
@@ -31,8 +31,8 @@
 
       <para>
 	&Evolution; puts the calendar storage in a daemon called the
-	Wombat and completely separates it from clients who wants to
-	access calendar data.  This part of the Wombat is called the
+	&Wombat; and completely separates it from clients who wants to
+	access calendar data.  This part of the &Wombat; is called the
 	personal calendar server, or &PCS;.  Clients must contact the
 	&PCS; and ask it to open an existing calendar or create a new
 	one.  When a calendar component object (e.g. an appointment or
@@ -80,9 +80,77 @@
 	<title>Recurrence and Alarm Queries</title>
 
 	<para>
-	  
+	  Looking for the events that recur or have alarm triggers in
+	  a specific period of time involves scanning all the
+	  appointments in a calendar.  To keep clients from having to
+	  load whole calendars at once, the &PCS; can do these
+	  computations and send the results to clients.
 	</para>
       </formalpara>
+
+      <formalpara>
+	<title>Modification Log</title>
+
+	<para>
+	  To allow multiple handheld devices to be synchronized
+	  against a calendar, the &PCS; keeps a log of all the
+	  modifications that are done to the calendar.  When an
+	  appointment is updated or removed, the &PCS; logs this
+	  action in the modification log.  Synchronization conduit
+	  programs can then use this information to do their work.
+	</para>
+      </formalpara>
+    </sect1>
+
+    <!-- Data Views -->
+
+    <sect1>
+      <title>Data Views</title>
+
+      <para>
+	&Evolution; provides a graphical calendar client inside the
+	shell that is just a view onto the data stored in the personal
+	calendar server.  You can launch as many views of a calendar
+	as you like and they will all receive notification from the
+	&PCS; when changes occur.  The views are then responsible for
+	updating their respective displays.
+      </para>
+
+      <para>
+	Even within a single calendar view in the &Evolution; shell
+	there can be multiple clients of a single calendar.  For
+	example, in the day view of the &Evolution; calendar there are
+	three widgets that act as three different clients of the
+	&PCS;:  the multi-day view, the busy days calendar, and the
+	task list.
+      </para>
+    </sect1>
+
+    <!-- Non-graphical Clients -->
+
+    <sect1>
+      <title>Non-graphical Clients</title>
+
+      <para>
+	Clients of the personal calendar server can be non-graphical,
+	that is, they do not have to provide views of the data to the
+	user.  Examples of such clients are the synchronization
+	conduit programs for handheld devices.  These usually run with
+	no user interface as a result of being invoked by a daemon
+	that watches the connection to a handheld device.  For
+	example, the calendar synchronization conduit in &Evolution;
+	gets run when the <application>gpilotd</application> daemon
+	from the <application>gnome-pilot</application> package
+	detects that the HotSync button has been pressed on a Palm
+	Pilot device.
+      </para>
+
+      <para>
+	Such clients simply take advantage of the centralized storage
+	in the &PCS; without presenting any graphical display of the
+	data; they just act as middlemen between the &PCS; and other
+	applications.
+      </para>
     </sect1>
   </chapter>
 
-- 
cgit v1.2.3