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
|
Things to do and people working on it
-------------------------------------
Step 1 - Infrastructure
1.1 DONE - Create SOAP management API in libsoup, in soup-soap-message.[ch]
to manage messages, and soup-soap-response.[ch] to manage responses
from the server.
1.2 DONE - Implement interface to Groupwise server, in
e-d-s/calendar/backends/groupwise/e-gw-connection.[ch], to manage
the connections to the server, and e-gw-message.[ch] for utility
functions to easily create SOAP messages to be sent to the server.
1.3 DONE - Implement login/logout to server, e_gw_connection_login and
e_gw_connection_logout, being called from e_cal_backend_groupwise_open
1.4 Map error codes returned in the "status" SOAP type to our
EGwConnectionStatus. This is in e-gw-connection.c#parse_response_status.
We need the list of status codes returned by the server from the GW team.
1.5 DONE - Write script/program to easily add an account until we have the configuration
GUI
Step 2 - Basic functionality
2.1 DONE - Make the ECalBackendGroupwise class use ECalBackendCache, so that after
first connecting to a server we can keep the calendar in the cache
2.2 DONE - Implement retrieval of objects, that will be saved to the cache. This is
probably best done by listening to modifications on the server, and updating
the cache whenever a change is made on the server. On the first connection,
we should probably retrieve all objects, or at least their UIDs.
This involves implementing the following methods on the backend:
- Implement e_cal_backend_groupwise_get_default_object, which
should return an empty object with the minimal required fields
(if any) the server might need.
- Implement e_cal_backend_groupwise_get_object, which must
retrieve the specified object from the cache, or from the server
if it's still not in the cache.
- Implement e_cal_backend_groupwise_get_timezone, which must
return a VTIMEZONE object representing the required timezone.
The server should have a list of available timezones, if not,
we can use libical's built-in timezones.
2.3 DONE - Retrieve information about connection : when loging to the server, we get, in
the loginResponse response, some information about the user being connected.
From that we can retrieve some information needed to implement the following
backend methods:
- Implement e_cal_backend_groupwise_is_read_only, which tells the
caller whether the given calendar is read only or not. If read only,
the GUI will disable all modifications-related options.
- Implement e_cal_backend_groupwise_get_cal_address, which returns
the associated email address with this calendar. This is the email
address of the user that opened the calendar.
- Implement e_cal_backend_groupwise_get_ldap_attribute
- Implement e_cal_backend_groupwise_get_alarm_email_address, which
returns the email address to use when sending alarms.
- Implement e_cal_backend_groupwise_get_static_capabilities, which
returns a list of the capabilities of the backend. Those capabilities
are listed in e-cal-backend.h
2.4 Implement modification of objects on the server. This involves adding,
removing and updating objects (either tasks, events or timezones) and
implementing the following methods on the backend:
- Implement e_cal_backend_groupwise_add_timezone, which adds
a VTIMEZONE to the calendar/tasks folder.
- Implement e_cal_backend_groupwise_set_default_timezone, which
sets the default timezone to use when no timezone is given. This
should probably also change the default timezone on the server, not
only locally.
- Implement e_cal_backend_groupwise_discard_alarm, which is used
to let the backend do whatever it needs to do in order to discard
an alarm. We probably need to do nothing here, apart from updating
the object on the server with the alarm removed (already removed by
the GUI).
- Implement e_cal_backend_groupwise_create_object, which is used
by clients to add new objects to the calendar/tasks folder.
- Implement e_cal_backend_groupwise_modify_object, used to modify
an already existing object on the server. If the object does not
exist, it must return an error, and not try to add the object.
- Implement e_cal_backend_groupwise_remove_object, which removes
an object from the server.
- Implement e_cal_backend_groupwise_receive_objects, used for iMIP/iTIP.
It should act more or less like modify/create_object. If it's an
external invitation, the event should be added to the calendar. If
it's a reply to an existing meeting, the related event should be
updated.
- Implement e_cal_backend_groupwise_send_objects, which lets the
server send a meeting invitation in whatever means it's got.
When sending modifications to the server, only deltas (the fields that have
been modified) are sent, so we should compare the objects with the cache
and get the deltas out of that. When a successful update is made to the
server, the cache must be updated.
2.5 DONE - Implement queries to the server. This involves implementing the following
backend methods:
- Implement e_cal_backend_groupwise_get_object_list, which returns
a list of objects that match a given regular expression.
- Implement e_cal_backend_groupwise_start_query, which makes the
backend start a query asynchronously.
- Implement e_cal_backend_groupwise_get_changes, which returns
a list of changes done to the calendar since a given date. For
this, we should probably use the same method the file backend
uses.
The question remaining here is what to do with the queries. Since we are
keeping a cache, I guess we should make all queries against the cache, instead
of contacting the server for each query, or making a cache of queries, like we
had in Evolution 1.4.
2.6 Free/Busy. This is the implementation of the e_cal_backend_groupwise_get_free_busy
method on the backend.
2.7 DONE - Addition/removal of calendars. The backend should be able to create new calendars
when the _open method is called with 'only_if_exists' set to FALSE. In that case,
it should create the new calendar, and add the new source to the calendar sources
tree. Make sure the new-calendar dialog should call that method (e_cal_open) to tell the
backend to create the calendar.
Also, the e_cal_backend_groupwise_remove method should be implemented to allow the
removal of those calendars.
2.8 Implement configuration of GW accounts.
Step 3 - Extra
3.1 DONE - Offline/Online mode:
- Implement e_cal_backend_groupwise_get_mode, which returns the current
online/offline mode of the backend.
- Implement e_cal_backend_groupwise_set_mode, used by clients to
change the online/offline status of the backend. When going offline,
the backend should synchronize its local copy, and when going back
online, synchronize back all changes made to the local cache. To
determine the set of changes, we can use a similar method to the one
used for the get_changes method.
3.2 Folder properties. Each calendar/tasks folder should be configurable from the
UI. The source selector widget will display a 'Properties' menu item in the
popup menu which will show up a dialog that allows the user to change the folder
properties (name, permissions, whatever). We need to decide on how this is done,
since the GUI should not know anything about Groupwise.
|
