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

List:       kmail-devel
Subject:    Re: Stuff
From:       Marc Mutz <mutz () kde ! org>
Date:       2002-07-30 23:11:30
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 30 July 2002 08:58, Don Sanders wrote:
<snip>
> Determining whether a message is already downloaded is obviously the
> duty of the mail client, I would be surprised if the abstraction
> between the mail client and message library was broken in KMime,
> after all it's in libkdenetwork so can't rely on kdenetwork/kmail
> header files.

I think it's a valid design decision to move as much common code as 
possible into the message library. With that I mean:
1. Message fetching and storing.
2. Creating replies, forwards, MDNs, ...
3. Searching, filtering
4. Composing and Reading

This doesn't mean it's going to end up in the message class. But it 
should go into the message lib. Think about all that duplicated code in 
KNode and KMail.

I find this ugly as hell.

> I do get annoyed at some of Marc's KMail architecture criticisms.
> Some of his criticisms are valid. However I feel that other
> criticisms are not valid. A simple bug or missing feature that is
> relatively easy to fix may be mistakenly labeled as a deep
> architectural problem.
<snip>

You know the KMail code since you wrote large parts of it. Others don't 
and others (including me) find it extremely difficult to work with it. 
What might be an easy fix for you might be a day-long bughunt for 
anyone else.

Adding a tiny feature can be horror because the code works against you 
instead of making it easy for you. I regularly gave up adding some 
feature that required me to special-case IMAP. Not because I wasn't 
able to cut'n'paste code, but because this stuff made me sick when 
looking at and I had no time to refactor it.

Which leads me to another point: missing refactoring. Fixing a few 
things here and another there leads to unmaintainable code in the long 
run. Some people have refactored parts of KMail and with success (I've 
done filters back then, Ingo did OpenPGP, Carsten the folder tree and 
you are currently doing the comands). I find it funny that the very 
core of KMail wasn't refactored in the last ~2 years at all. No, I 
don't find it funny. I find it precarious.

I think that also KMail's core has to be refactored or rewritten once a 
while. And be it only to let the then-current developers create a 
common thing they all understand well.

To sum up: I agree that most of the shortcomings are fixable based on 
the current design decisions. That doesn't mean it has to be done that 
way. Honestly, I believe that sometimes it's better to break than to 
bend.

Marc

Mutig warf sich die kleine Überwachungskamera zwischen Täter und Opfer!
                                          --Rena Tangens / FoeBuD e.V.
- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Rx0j3oWD+L2/6DgRArObAJ9NDcqWxXRvxur2DhFNmaRRFWz5VwCgvS6j
IBJY0C5rKuThQz8GFk8/4cs=
=HaBG
-----END PGP SIGNATURE-----

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]