aboutsummaryrefslogtreecommitdiffstats
path: root/doc/devel/calendar/architecture.sgml
diff options
context:
space:
mode:
Diffstat (limited to 'doc/devel/calendar/architecture.sgml')
-rw-r--r--doc/devel/calendar/architecture.sgml94
1 files changed, 0 insertions, 94 deletions
diff --git a/doc/devel/calendar/architecture.sgml b/doc/devel/calendar/architecture.sgml
deleted file mode 100644
index 08e4c82b35..0000000000
--- a/doc/devel/calendar/architecture.sgml
+++ /dev/null
@@ -1,94 +0,0 @@
- <chapter id="calendar-architecture">
- <title>Architecture of the Calendar</title>
-
- <para>
- This chapter gives an overview of the Evolution Calendar
- architecture. It describes the model/view split of the calendar
- into a personal calendar server, or PCS, and the GUI clients
- that appear inside the Evolution shell.
- </para>
-
- <!-- Model/View Separation -->
-
- <sect1 id="calendar-model-view">
- <title>Model/View Separation</title>
-
- <para>
- Like other base components in Evolution, the calendar
- separates the data model from the views or clients. This is
- done so that multiple clients can access the same calendar
- data in an orderly fashion and without clashes. For example,
- the user may be running a graphical calendar client. If he
- then wants to synchronize his calendar with a handheld device,
- then the corresponding synchronization program (e.g. a conduit
- for the <application>gnome-pilot</application> package) will
- also need to access the calendar storage. It is important
- that both the GUI client and the synchronization program keep
- a consistent view of the calendar at all times, otherwise one
- of them will be left in an inconsistent state if the
- calendar's data changes unexpectedly.
- </para>
-
- <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
- 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
- to-do item) changes in the &PCS; it will notify all the
- clients that are using the component's parent calendar.
- </para>
- </sect1>
-
- <!-- Personal Calendar Server -->
-
- <sect1>
- <title>Personal Calendar Server</title>
-
- <para>
- The personal calendar server, or &PCS;, provides centralized
- management and storage of a user's personal calendar.
- Multiple clients can connect to the &PCS; simultaneously to
- query and modify the user's calendar in a synchronized
- fashion. The main features of the &PCS; are as follows:
- </para>
-
- <formalpara>
- <title>Storage</title>
-
- <para>
- The &PCS; is responsible for loading and saving calendars.
- Centralizing the loading and saving functionality allows
- multiple clients to use the same calendar at the same time
- without having to worry about each other.
- </para>
- </formalpara>
-
- <formalpara>
- <title>Basic Queries</title>
-
- <para>
- The &PCS; provides functions to do basic queries on a
- calendar, for example, a client can ask the server for a
- list of all the appointments in the calendar, or for all the
- data for a specific appointment.
- </para>
- </formalpara>
-
- <formalpara>
- <title>Recurrence and Alarm Queries</title>
-
- <para>
-
- </para>
- </formalpara>
- </sect1>
- </chapter>
-
-<!--
-Local variables:
-mode: sgml
-sgml-parent-document: ("../evolution-devel-guide.sgml" "book" "part" "")
-End:
--->