Re: [Evolution-hackers] Offline mode improvements
On Wed, 2002-04-24 at 15:46, 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. Rather, we just sync Inboxes. >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). And you forgot to mention the Clever Hack for this, which is that the mailer needs to claim that vfolders are syncable, and then you create a vfolder that selects the kinds of messages you want to sync, and tell the shell to sync only that folder. I think this was considered an enhancement on top of the must-happen-for-1.2 stuff though. -- Dan ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
On Wed, 2002-04-24 at 15:57, Dan Winship wrote: > And you forgot to mention the Clever Hack for this, which is that the > mailer needs to claim that vfolders are syncable, and then you create a > vfolder that selects the kinds of messages you want to sync, and tell > the shell to sync only that folder. I think this was considered an > enhancement on top of the must-happen-for-1.2 stuff though. Yeah. I actually didn't mention it here because it's independent from the shell hackery, and also because I am not sure if this requires extra work on Camel. Would claiming that the vfolders are syncable Just Work (tm)? -- Ettore ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
On Thu, 2002-04-25 at 05:46, Ettore Perazzoli wrote: > On Wed, 2002-04-24 at 15:57, Dan Winship wrote: > > And you forgot to mention the Clever Hack for this, which is that the > > mailer needs to claim that vfolders are syncable, and then you create a > > vfolder that selects the kinds of messages you want to sync, and tell > > the shell to sync only that folder. I think this was considered an > > enhancement on top of the must-happen-for-1.2 stuff though. > > Yeah. I actually didn't mention it here because it's independent from > the shell hackery, and also because I am not sure if this requires extra > work on Camel. Would claiming that the vfolders are syncable Just Work > (tm)? Not that I know of. Stores that are capable of working offline use a different class heirarchy, and well, it wouldn't make sense at all for vfolders to be in that class heirachy since they are never connected or otherwise. IMHO its not a very good idea anyway. Hence the use of 'hack' to describe it. We can just use the vfolder dialogue to specify rules on a per store or even per-folder basis, and just do all the processing in camel as it is done now (although the disconnected store code has a lot of problems like poor thread safety). We only need to add a small interface to a disconnectable store to say what search to perform to sync stuff against. I would guess that just using a set of rules per store would suffice. Although the rule set would work similarly to the vfolder code, there's not enough commonality to use the vfolder code, and in total its only a dozen lines of code or so anyway. ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
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") |
> | |
> | [XXX] |
> | |
> +---+
> |[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
Re: [Evolution-hackers] Offline mode improvements
On Wed, 2002-04-24 at 20:02, Not Zed wrote: > 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. Sweet. As a first try, I think we should just go for the "sync all the messages in all the specified folders" approach though. > > /* 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. Hm. We should change is so it's done at folder level then. At least, that's the way it should look from the shell's side (it doesn't matter how Camel does it). Otherwise we can't unify the process of selecting which folders need to be synced across all components. (See, one thing that we want is also being able to sync calendars, and that has to work independently of the mailer, and independently of whether the rest of the store is synced or not.) > > void updateProgress (in unsigned percent); > > Is there a way to use the same progress code or at least interface, as > in other cases? Hm, the ::Activity interface assumes that the actions are controlled by the component. In this case, instead, we want the shell to initiate the operation and the component to just report how the operation is progressing. > 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. I am not sure I understand what you mean here. In what cases would we want this? I don't think this is necessary for the specific case of going offline, although I can see why you would want to share the behavior and code... (But still, see my comment above the difference in the two interfaces.) > > 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? See, that's the thing. We should change this so that whether the syncing is performed is decided on a per-folder basis, not a per-store basis. > 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. I was not considering the rules for now. Although, I think we can have sync rules per folder as well, by using this approach... We would just need a slightly more complex interface. > > 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. OK, can you please let us know how much work is needed to make the offline code do all of this? I think we can completely drop the issue of per-folder rules, although of course it would be nice to design this so that can be plugged in easily at a later time. -- Ettore ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
On Fri, 2002-04-26 at 05:53, Ettore Perazzoli wrote: > On Wed, 2002-04-24 at 20:02, Not Zed wrote: > > 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. > > Sweet. As a first try, I think we should just go for the "sync all the > messages in all the specified folders" approach though. > > > > /* 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. > > Hm. We should change is so it's done at folder level then. At least, > that's the way it should look from the shell's side (it doesn't matter > how Camel does it). Otherwise we can't unify the process of selecting > which folders need to be synced across all components. (See, one thing > that we want is also being able to sync calendars, and that has to work > independently of the mailer, and independently of whether the rest of > the store is synced or not.) > > > > void updateProgress (in unsigned percent); > > > > Is there a way to use the same progress code or at least interface, as > > in other cases? > > Hm, the ::Activity interface assumes that the actions are controlled by > the component. In this case, instead, we want the shell to initiate the > operation and the component to just report how the operation is > progressing. Ugh. Sounds messy. > > 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. > > I am not sure I understand what you mean here. In what cases would we > want this? > > I don't think this is necessary for the specific case of going offline, > although I can see why you would want to share the behavior and code... > (But still, see my comment above the difference in the two interfaces.) > > > 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? > > See, that's the thing. We should change this so that whether the > syncing is performed is decided on a per-folder basis, not a per-store > basis. Well, personally, I dont think so. You need to at least pass all folders in a list, not a separate corba call for each one. > > 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. > > I was not considering the rules for now. Although, I think we can have > sync rules per folder as well, by using this approach... We would just > need a slightly more complex interface. > > > > 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. > > OK, can you please let us know how much work is needed to make the > offline code do all of this? I think we can completely drop the issue > of per-folder rules, although of course it would be nice to design this > so that can be plugged in easily at a later time. Sure, although i dont really see the point of wasting the time doing it if its just going to have to be redone properly later. ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
> > Hm, the ::Activity interface assumes that the actions are controlled by > > the component. In this case, instead, we want the shell to initiate the > > operation and the component to just report how the operation is > > progressing. > > Ugh. Sounds messy. Why? > > See, that's the thing. We should change this so that whether the > > syncing is performed is decided on a per-folder basis, not a per-store > > basis. > > Well, personally, I dont think so. Well, that's how we want it to work for 1.2. The user should be able to decide that, say, he wants to sync up all his work email but not sync up the junk from some mailing list. > You need to at least pass all folders in a list, not a separate corba > call for each one. Why? If we want the UI to show progress to the user in the form that I explained, then that's the only way to do it. > Sure, although i dont really see the point of wasting the time doing it > if its just going to have to be redone properly later. Then you should at least define what "properly" means. -- Ettore ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
On Mon, 2002-04-29 at 10:10, Ettore Perazzoli wrote: > > > Hm, the ::Activity interface assumes that the actions are controlled by > > > the component. In this case, instead, we want the shell to initiate the > > > operation and the component to just report how the operation is > > > progressing. > > > > Ugh. Sounds messy. > > Why? Because the code to handle progress reporting is already very messy (because of ORBit 'races' mostly, esp interacting with mt code), and this will probably require a duplication of a lot of that code, as well as a mechanism to select one of them. It can be done, it will just be messy. > > > See, that's the thing. We should change this so that whether the > > > syncing is performed is decided on a per-folder basis, not a per-store > > > basis. > > > > Well, personally, I dont think so. > > Well, that's how we want it to work for 1.2. The user should be able to > decide that, say, he wants to sync up all his work email but not sync up > the junk from some mailing list. I think it should be rules based on the store. This gives the maximum flexibility (by using rules, you can sync anything, e.g. not sync messages with attachments? attachments at all?), performance/scalability and features (asynchronous idle-time syncing?) and maintaining consistency (what happens if new mail arrives for folder A that you've already synced, while you're syncing folder B?). It is conceptually an atomic operation, it is really part of going offline, its not some operation you just do once in a while to an arbitrary folder because you feel like it. But since 'we' know what 'we' want for 1.2, I guess there's no point discussing it. > > You need to at least pass all folders in a list, not a separate corba > > call for each one. > > Why? If we want the UI to show progress to the user in the form that I > explained, then that's the only way to do it. "the only way to do it" What an absurd statement! You know that is simply not true, this is software we're talking about, not physics. There are an unlimited number of ways to do it. You could pass a path parameter to the progress report, you could run a perl script that starts a tcl/tk program to show the progress if you wanted to, you could do any number of things, although many of them would obviously not be ideal. Infact there's very little requirement for each folder to be listed as synchronising separately anyway. But again, if thats the way you want it to work, thats the way it'll be done. > > Sure, although i dont really see the point of wasting the time doing it > > if its just going to have to be redone properly later. > > Then you should at least define what "properly" means. You said yourself that we want to add specific rules later on, for example. But anyway, i'd rather not argue about it it at all anymore, this is entirely counter productive. It'll probably take about a day or two to do the mailer code and test it, assuming the other interfaces are there and work, and you dont hit some unexpected problems (i'm relying on my memory of how progress notifications work which is a bit rusty). ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
> performance/scalability and features (asynchronous idle-time syncing?) > and maintaining consistency (what happens if new mail arrives for folder > A that you've already synced, while you're syncing folder B?). It is > conceptually an atomic operation, it is really part of going offline, > its not some operation you just do once in a while to an arbitrary > folder because you feel like it. I was not making it happen randomly at times. It would be invoked after ::prepareForOffline. > "the only way to do it" "Only sane way to do it". :-) > What an absurd statement! You know that is simply not true, this is > software we're talking about, not physics. There are an unlimited > number of ways to do it. You could pass a path parameter to the > progress report, you could run a perl script that starts a tcl/tk > program to show the progress if you wanted to, you could do any number > of things, although many of them would obviously not be ideal. Infact > there's very little requirement for each folder to be listed as > synchronising separately anyway. I don't see how you make the different components deal with a unified dialog and syncing one folder at a time, if they are not directed by the shell into doing the syncing operation. -- Ettore ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
On Wed, 2002-05-01 at 06:08, Ettore Perazzoli wrote: > > performance/scalability and features (asynchronous idle-time syncing?) > > and maintaining consistency (what happens if new mail arrives for folder > > A that you've already synced, while you're syncing folder B?). It is > > conceptually an atomic operation, it is really part of going offline, > > its not some operation you just do once in a while to an arbitrary > > folder because you feel like it. > > I was not making it happen randomly at times. It would be invoked after > ::prepareForOffline. Well the api doesn't forace anything. > > "the only way to do it" > > "Only sane way to do it". :-) In your opinion. > > What an absurd statement! You know that is simply not true, this is > > software we're talking about, not physics. There are an unlimited > > number of ways to do it. You could pass a path parameter to the > > progress report, you could run a perl script that starts a tcl/tk > > program to show the progress if you wanted to, you could do any number > > of things, although many of them would obviously not be ideal. Infact > > there's very little requirement for each folder to be listed as > > synchronising separately anyway. > > I don't see how you make the different components deal with a unified > dialog and syncing one folder at a time, if they are not directed by the > shell into doing the syncing operation. Yeah, you dont. What has that got to do with it? I thought of another thing this morning ... what about cancellation? Any long, or potentially timeout'ing operation should be cancellable, shouldn't it? ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
> I thought of another thing this morning ... what about cancellation? > > Any long, or potentially timeout'ing operation should be cancellable, > shouldn't it? ::cancelSyncFolder() in my proposal. -- Ettore ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Offline mode improvements
On Thu, 2002-05-02 at 01:45, Ettore Perazzoli wrote: > > I thought of another thing this morning ... what about cancellation? > > > > Any long, or potentially timeout'ing operation should be cancellable, > > shouldn't it? > > ::cancelSyncFolder() in my proposal. Umm, but sync is a synchronous method. There's nothing to say that cancelSyncFolder() could ever get a chance to execute till after syncFolder() returns. And re-entrant corba calls are a world of pain. ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
