aboutsummaryrefslogtreecommitdiffstats
path: root/help/devel/calendar/architecture.sgml
blob: d261f0a7f4980bd60fd0c7d1a1a994952eb91613 (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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
  <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:
-->