diff options
Diffstat (limited to 'help/devel')
| -rw-r--r-- | help/devel/ChangeLog | 5 | ||||
| -rw-r--r-- | help/devel/calendar/architecture.sgml | 74 |
2 files changed, 76 insertions, 3 deletions
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> |