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.

