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
