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

On Tue, 2002-04-09 at 09:47, Not Zed wrote:
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.

OK... If you can tell me how to backtrace or where I can find info
on how to do that I would be happy to help you guys out when it 
happens again. 

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.

OK. I can understand that, but what I really mean is that a lot
of people will use evolution as a mail client and nothing more.
I for one, will _never_ receive meeting requests at my home
machines and I guess you know as good as I that the largest 
portion of users _will_ be home users. And in the exceptional
case that I might receive a meeting request, I really wouldn't
care of it took 10sec to start the calendar or give me a msg
that I need to start the calendar. And these things should
be enabled by default, I just would like a clean option to
*not* start them...
eg. evolution --no-calendar --no-summary
This would be a really cool feature that I allways lacked 
in the ancient times when I used outlook, you have the same
situation there. 80% of the windows users I know, work with
outlook to read their mail, but maybe 5% uses the calendar
I run evo now without calendar and summary, and disabled the
shortcut bar. Well it's just the *perfect* mua if you ask
me... You could realy reach a wider audience if you ask me,
'cause a lot of people want a mail-client, not 'bloatware' as
_they_ call it (these are not my words, but a lot of people
look at it that way). And I think the larger the userbase,
the larger the feedback, the better the product gets... No?

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

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).

I think the best way is to just cache the MIMEs during the session and
keep the headers in permanent cache... 
But that's just my opinion... 
How do other people look at this???



"Computer games don't affect kids;           
 I mean if Pac-Man affected us as kids,       
 we'd all be running around in darkened rooms, 
 munching magic pills and listening to         
 repetitive electronic music."
 -- Kristian Wilson, Nintendo, Inc, 1989

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]