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
