[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: KMail last of 16 Win/Mac/Linux Mail Clients in c't test!
From:       Don Sanders <sanders () kde ! org>
Date:       2001-05-05 17:05:16
[Download RAW message or body]

On Saturday 05 May 2001 16:40, Nicholas Hagen wrote:
> Well,
>
> Personally, I find this analysis lopsided and geared towards over excessive
> and bloated programs.

I think that is definitely true. But this is a deficiency of the computer 
media in general, always interested in cool new features to talk about rather 
than the deeper question of how to objectively measure the quality of an 
application. The c't review is not unusual in this respect.

In large part this stems from the fact that measuring quality would require 
investigating factors like reliability and ease of use over the long term and 
this is very, very expensive compared to going through a check list of 
features and seeing which ones an application supports (or pretends to 
support).

Indeed (not having read the review) c't seems to have made some effort to go 
beyond superficial details, (by trying a developmental version of KMail) 
which is commendable. On the other hand I'm not sure how closely they looked 
at KMail if they missed features like APOP and "Reject Return Receipts" 
support. (Maybe they also missed the existence of kmailcvt and think KMail 
can't import mail from other clients)

>  Most of those programs have been around for times
> and now exist in severe uneccessary bloat.  KMail has stuck to its simple,
> easy to
> use nature.  And even as we add more functionality to it, it still stays
> unbloated.

Over the past few years I've spent the majority of my time ignoring people's 
requests for new features (I would use KMail if only it could...) and instead 
concentrated on trying to improve the existing KMail functionality. That 
means trying really hard to find and fix mail losing bugs, fixing annoyances, 
fixing performance (memory/speed) problems, making sense of garbage sent by 
other mail clients (eg. decent threading),  etc.

Basically I've tried to make current users happier, in a few areas I've 
failed to do that. Specifically SMTP-Auth and SMTP-after-POP support are 
becoming popular and KMail hasn't keep current there.

I feel that the majority of features KMail was criticized for not supporting 
are useful features that are desirable to support, they are features that 
will be supported, but the implementation should be done well rather than 
quickly.

> Anyways, I'm not quite sure how they can consider KMail a not so good
> application.
> I sure don't.

KMail is geared towards the needs of KDE users, a lot of which are KDE 
developers. These are people who subscribe to numerous, mainly plain text 
based, high volume mailing lists. KMail serves these people increasingly 
well, more and more KDE developers are using KMail and this means more to me 
than the results of a c't review.

KMail is not so optimized for the masses, including mum's, grandpa's, family 
pets and c't reviewers, (and to be honest this doesn't bother me much).

I feel that the inclusion of KMail as one of the few linux clients reviewed 
is a complement. It indicates KMail is popular in spite of the fact that is 
doesn't support some popular features. I believe this is partly because while 
we don't do everything, what we do, we do well and I'm proud of that.

Ok, I think I talked far too much today and coded far too little.

BFN,
Don.
_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]