Hello,
So, we need to make offline support better before 1.2 goes out. Right
now offline support sucks in the following ways:
1. We don't allow specifying which folders should be synced -- we
just sync them all.
2. We don't allow specifying any criteria for how folders should be
synced up (e.g. whether to sync all the messages, or only the
messages that are unread, or whatever).
3. We don't have a nice progress dialog showing how much of the
synchronization has happened. Also, you can't cancel the operation
nicely.
So, we need to fix up the offline interfaces a bit. Here is a
proposal of how I think we should do it; please follow-up soon so I
can start hacking it up in the shell, and we can have it working in
the components ASAP.
Right now we handle offline mode by using the Evolution::Offline
interface. The interface has three methods and one attribute:
/* Whether the component is currently off-line. */
attribute boolean isOffline;
/* Ask the component to prepare to go into off-line mode. The
component must return a list of the current active connections.
After this call, the shell is expected to either invoke
`::goOffline()' (actually complete the operation and go off-line) or
`::goOnline()' (operation cancelled). */
void prepareForOffline (out ConnectionList active_connection_list);
/* Ask the component to go into off-line mode. This always comes after
a `::prepareForOffline' only. */
void goOffline (in OfflineProgressListener listener);
/* Tell the component to go into on-line mode. */
void goOnline ();
With this interface, the shell doesn't really care what happens when
the component goes offline. The component can sync up the folders
locally, but that's not mandated in the interface. Also, the only
form of progress reporting is the OfflineProgressListener which only
has one method:
/* Update the shell about the progress of going off-line. The
operation is considered completed when the ConnectionList is empty. */
void updateProgress (in ConnectionList current_active_connections);
Instead of this, I propose that we add two methods like the following
to the Evolution::Offline interface:
/* Request the component to sync the specified folder. */
void syncFolder (in string evolution_uri,
in string physical_uri,
in SyncFolderProgressListener listener);
/* Request the component to stop syncing the specified folder. */
void cancelSyncFolder (in string evolution_uri,
in string physical_uri);
When the shell invokes ::syncFolder, the component will just start
syncing the folder at the specified URI and report progress on
@listener. SyncFolderProgressListener could be something simple like
this:
void updateProgress (in unsigned percent);
>From a GUI perspective, instead of just the connection list, we could
have a nice progress dialog like this: (ph34r my ASCII art GUI design
skillz)
+---------------------------------------------------+
| |
| Synchronizing folder 2 of 10 ("Inbox") |
| |
| [XXXXXXXXXXXXXXX ] |
| |
+---------------------------------------------------+
| [Cancel] |
+---------------------------------------------------+
Or something (Anna? :-)).
Now, the shell will also have to be able to specify the list of
folders that can be synced in offline mode. The way we would do this
is by having a configuration page of some kind. This would display an
ETree with checkboxes, and the user would be able to select the
folders by clicking on multiple checkboxes. I.e. the list of folders
to sync will be completely kept in the shell. (Anna, we need a design
for this as well.)
On the other hand, not all the folders can be synced. So I propose
that we add a `canSyncOffline' property to the Evolution::Folder type.
This way, each component can specify whether a folder in one of its
storage support offline operation or not. [Of course, local folders
don't need to be synced so will always have the canSyncOffline bit set
to %FALSE.]
How does this sound? If no-one objects, I am going to start to hack
this early next week (after I am done with the CDE work this week).
Then we need to make the mailer support it, and I was thinking this
could be Michael's task. Michael, what do you think?
--
Ettore
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
