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
