Re: [Evolution] Feature requests: modularity & imap caching...

[Not Zed <notzed ximian com>]

On Tue, 2002-04-09 at 02:54, Frederic Vanneste wrote:
> First of all, kudos to the whole Ximian team for
> putting together this IMO excellent product.
> After some fiddling it became my client of choice
> and I haven't had any issues in months except
> for some 'closing' problems (Waiting for component
> to die -- ...) from time to time.

Is it just busy, or really hung?  Sometimes it could be busy for a long
time.  If it has hung (most notably if the application isn't using any
cpu and the disk is idle, etc), a backtrace and bug report will help us
identify and fix it.

> First proposal/request:
> I like the essential idea behind the workgroup/pim
> features, but I'd rather have a choice. Let me 
> explain... I use evolution mainly because of its
> _great_ imap-handling, it's the first (gui) mua
> that really does everything I need and does it
> _right_! But I only use the calendar-thingy
> on one system, and I *know* there are a lot of
> people that rarely of never use the calendar/tasks
> features. The summary feature is a nice addition,
> but it's a not really something everyone *needs*, right?
> Don't get me wrong, I really like those features, on 
> my main system they are all enabled, but what I mean
> is that these should be 'options/plugins/whatever'.
> I managed to get evolution run as an imap-client only,
> by renaming the oaf files, so they're not loaded on 
> startup, but it would be really nice if there was a
> more 'clean' way of doing that. Because of the
> nice modularity in the code of evolution, I 'guess'
> that would not be such a major obstacle to overcome
> (correct me if I'm wrong here, I'm not much of
> a programmer...).

The problem is, for example, if you receive a meeting request, the
mailer assumes the calendar component is available, and/or tries to
start it up to handle it.  And because of the terribly slow startup
process, and to help with debugging, these things are just started all
the time.

> Second, it would be really nice if you get more
> control over the imap caching. I work in mechanical
> engineering and get a lot of large files in my
> mailbox. Header caching is a major feature, but
> I hate it that I have to manually delete all those
> mime-files from the cache... You must understand that
> if you read your mail on different systems,
> all those files (of sometimes a couple megs each)  get 
> cached in all those places, taking a couple of 100Megs on
> each system after a couple of weeks. 
> It would really be nice if there was an option to purge
> the mime-cache on exit/command/...

I agree.  The cache isn't really a cache at all, it is just a
disk-backing that never seems to get cleared unless the folder becomes
invalid.

The NNTP code has a better cache design, but it hasn't been integrated
into IMAP yet, and may not for a while because the existing code is a
little tightly integrated with the operation of imap.  And .. a cache
clearing option isn't that easy to add because of abstraction (i.e. the
mailer doesn't know if the store its talking to even uses one, e.g.
local mail).