On Thu, 2002-04-25 at 05:16, Ettore Perazzoli wrote:
> 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).
Actually re my other mail, we dont even have to do as much as I said.
We already specify the match rules to use from the mailer, so we have to
do very little if anything in camel to implement it.
> 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);
But syncing is done at the store level, not the folder level.
> /* 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);
Is there a way to use the same progress code or at least interface, as
in other cases?
I think, fortunately, we're able to separate this stuff from camel by
using identical code and just redirecting it from the mailer, so i guess
its no big deal (for us at least).
However, a couple of other cases could probably benefit from a pop-up,
cancellable progress indicator, so surely it would make sense to include
an extra interface/method to the activity client progress bar which just
displays differently and can be re-used.
> >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.]
I dont think this is required. Whether syncing can be performed or not
is decided at the store level, why pollute each folder description this
info?
Also, if you're going to have the shell keep track of the folders, it'll
have to keep track of the rules too ... so how do you specify
addressbook offline rules etc etc.
> 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?
I will have to review the whole offline code. What i've seen so far
looks pretty awful.
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
