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
