From ce1f72922f81fa83d2531adc93d3b733ec475f59 Mon Sep 17 00:00:00 2001 From: Federico Mena Quintero Date: Thu, 30 Nov 2000 02:43:57 +0000 Subject: Finished the calendar architecture chapter. 2000-11-29 Federico Mena Quintero * calendar/architecture.sgml: Finished the calendar architecture chapter. svn path=/trunk/; revision=6729 --- help/devel/ChangeLog | 5 +++ help/devel/calendar/architecture.sgml | 74 +++++++++++++++++++++++++++++++++-- 2 files changed, 76 insertions(+), 3 deletions(-) (limited to 'help/devel') diff --git a/help/devel/ChangeLog b/help/devel/ChangeLog index a8b4069d35..74b9899aef 100644 --- a/help/devel/ChangeLog +++ b/help/devel/ChangeLog @@ -1,3 +1,8 @@ +2000-11-29 Federico Mena Quintero + + * calendar/architecture.sgml: Finished the calendar architecture + chapter. + 2000-11-29 Federico Mena Quintero * evolution-devel-guide.sgml: Added an id for the API reference . 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 @@ &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 @@ Recurrence and Alarm Queries - + 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. + + + Modification Log + + + 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. + + + + + + + + Data Views + + + &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. + + + + 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. + + + + + + + Non-graphical Clients + + + 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 gpilotd daemon + from the gnome-pilot package + detects that the HotSync button has been pressed on a Palm + Pilot device. + + + + 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. + -- cgit