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.