diff options
Diffstat (limited to 'doc/devel/calendar/architecture.sgml')
| -rw-r--r-- | doc/devel/calendar/architecture.sgml | 162 |
1 files changed, 0 insertions, 162 deletions
diff --git a/doc/devel/calendar/architecture.sgml b/doc/devel/calendar/architecture.sgml deleted file mode 100644 index d261f0a7f4..0000000000 --- a/doc/devel/calendar/architecture.sgml +++ /dev/null @@ -1,162 +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> - 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> - -<!-- -Local variables: -mode: sgml -sgml-parent-document: ("../evolution-devel-guide.sgml" "book" "part" "") -End: ---> |