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
- - Implement e_cal_backend_groupwise_get_object
- - Implement e_cal_backend_groupwise_get_timezone
+ - 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 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
- - Implement e_cal_backend_groupwise_get_cal_address
+ - 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
- - Implement e_cal_backend_groupwise_get_static_capabilities
+ - 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
- - Implement e_cal_backend_groupwise_set_default_timezone
- - Implement e_cal_backend_groupwise_discard_alarm
- - Implement e_cal_backend_groupwise_create_object
- - Implement e_cal_backend_groupwise_modify_object
- - Implement e_cal_backend_groupwise_remove_object
- - Implement e_cal_backend_groupwise_receive_objects
- - Implement e_cal_backend_groupwise_send_objects
+ - 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 shoould compare the objects with the cache
and get the deltas out of that. When a successful update is made to the
2.5 Implement queries to the server. This involves implementing the following
backend methods:
- - Implement e_cal_backend_groupwise_get_object_list
- - Implement e_cal_backend_groupwise_start_query
- - Implement e_cal_backend_groupwise_get_changes
+ - 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
Step 3 - Extra
3.1 Offline/Online mode:
- - Implement e_cal_backend_groupwise_get_mode
- - Implement e_cal_backend_groupwise_set_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
projects / platform / upstream / evolution-data-server.git / commitdiff