aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--doc/devel/ChangeLog5
-rw-r--r--doc/devel/calendar/architecture.sgml74
-rw-r--r--help/devel/ChangeLog5
-rw-r--r--help/devel/calendar/architecture.sgml74
4 files changed, 152 insertions, 6 deletions
diff --git a/doc/devel/ChangeLog b/doc/devel/ChangeLog
index a8b4069d35..74b9899aef 100644
--- a/doc/devel/ChangeLog
+++ b/doc/devel/ChangeLog
@@ -1,5 +1,10 @@
2000-11-29 Federico Mena Quintero <federico@helixcode.com>
+ * calendar/architecture.sgml: Finished the calendar architecture
+ chapter.
+
+2000-11-29 Federico Mena Quintero <federico@helixcode.com>
+
* evolution-devel-guide.sgml: Added an id for the API reference <part>.
Added the FDL <legalnotice>.
Added the preface and toplevel reference entities.
diff --git a/doc/devel/calendar/architecture.sgml b/doc/devel/calendar/architecture.sgml
index f121144d29..d261f0a7f4 100644
--- a/doc/devel/calendar/architecture.sgml
+++ b/doc/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>
diff --git a/help/devel/ChangeLog b/help/devel/ChangeLog
index a8b4069d35..74b9899aef 100644
--- a/help/devel/ChangeLog
+++ b/help/devel/ChangeLog
@@ -1,5 +1,10 @@
2000-11-29 Federico Mena Quintero <federico@helixcode.com>
+ * calendar/architecture.sgml: Finished the calendar architecture
+ chapter.
+
+2000-11-29 Federico Mena Quintero <federico@helixcode.com>
+
* evolution-devel-guide.sgml: Added an id for the API reference <part>.
Added the FDL <legalnotice>.
Added the preface and toplevel reference entities.
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 02:27:50 +0800