aboutsummaryrefslogtreecommitdiffstats
path: root/help/devel/calendar/architecture.sgml
blob: 08e4c82b35c41c83381b608a3ec6fe4cf9eb55fe (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
  <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:
-->