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
|
LIBKCAL
=======
libkcal provides the non-GUI part of calendaring. It is partly based
on libical, an implementation of the iCalendar format defined in
rfc2445. libical is an object-oriented C library, which provides basic
but complete handling of calendaring components. libkcal puts a C++
face on it, which fully encapsulates the library.
Calendaring data is handled by the Calendar class interface, which
provides a storage for calendar components. One implementation of the
Calendar interface exists, the CalendarLocal class, which provides
local storage as a file. (TODO: Explain the resources.)
The Calendar class uses the CalFormat class interface to convert
calendar data into a textual representation. There are two
implementations, the VCalFormat for vCalendar and the ICalFormat for
iCalendar.
Actual calendaring components are handled by the classes Event, Todo
and Journal, all inheriting from the common base class
Incidence. These classes store the information related to an event,
todo or journal entry.
Specifics
=========
This is the place to put in developer notes for various specific
places that need extra description.
The scheduling ID
-----------------
In the Incidence class, there is an attribute called mSchedulingID.
It is only set when you have an event or to-do that is the result of
accepting an invitation. In this case it is the value of the UID of
the invitation, and is used for looking up the event if you get
changes to the original invitations - changes, canceling, updates...
The get-method that returns the schedulingID checks if this is set
at all. If not, it returns the UID. And when the incidence is saved in
iCal, the schedulingID (i.e. the UID if no SID is there) is saved in
the iCal UID field, and if schedulingID is not null, the UID of the
incidence is saved in X-TDE-LIBKCAL-ID. The reason for this is
compatibility with other iCal based applications, because they expect
the UID of the invitation to be saved in the iCal UID field. In the
Kolab resource XML format, there is a tag <scheduling-id> where it is
stored if present.
This is the scenario that led to the introduction of this scheme: If
you have access to some other persons calendar - for example with the
IMAP or Kolab resources using shared folders - and both you and the
other accept the same invitation, then you both have an event with the
same SID. Had this been the UID (as was previously the case and as is
done by other applications) then you would have two incidences with
the same UID, and libkcal is designed with a very basic assumption
that this must never happen. By storing the UID in SID and making a
new and private UID, there is still the link to the invitation UID
that is necessary for scheduling, and the UIDs of the two incidences
in your calendar are different. The scenario that really has this
problem is the secretary scenario - the secretary will often be at the
same events as the boss, and has access to the boss' folders. This
means he or she would see this problem all the time.
|
