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

List:       kmail-devel
Subject:    Why, oh why? -or- scoring
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-06-01 12:13:01
[Download RAW message or body]

Hi!

IIRC, scoring is a relatively new feature. So one should expect that 
the implementor is interested more in clean abstraction than in quickly 
hacking this feature in, having had a look at kmheaders.cpp and 
friends, right?

Alas, it is not so!

I was looking for a way to determine the score of a message, intending 
to add a "message score" search pattern rule. But what did my bloodshot 
eyes see? The whole scoring business is nicely woven into KMHeaders. In 
fact, mScoringManager is a member of KMHeaders!!!

Why isn't there a kernel->scoringManager()? I reckon that implementing 
somthing that smells like filtering should be implemented along the 
lines that the earlier filtering code was programmed along, no?

Why can't I just use something like
Q> msgScre = kernel->scoringManager()->score(myMsg);

Why must I replicate large chunks of code from KMHeaders if I want to 
add a trivial filter action or search rule?

Why was a KNode class (I assume this, because scoring has to be done by 
creating a KScorable_Article_, which simply takes the message as 
string), w/o further integration into the KMail framework, brutally 
pushed into KMail just to implement a rarely-used feature?

To the one that implemented scoring in KMail (and I somehow doubt that 
this is Espen Sand, as stated in kmscoring.h...):

If you care for filtering based on "score" or a "set score", "add 
score" etc. filter action, you have two options:

1.) Do it yourself (I'd be glad to help you with the filtering 
framework, but mind: the conditions in (2) should be met)
2.) make it possible to score a message
a. with no parent folder
b. without big overhead
c. from outside KMHeaders
d. without replicating too much code from KMheaders.
3.) Tell me how I can do (2) within the current framework.

It's getting boring to be caught in the following cycle:

a. Hm, let's implement this filter action. Should be trivial. Well, the 
functionality is already there, so it _must_ be quite simple.
b. Hm, how does the rest of KMail do it? Eeek, it's KMheaders again.
c. Oh, well. Let's see how KMheaders does it. Maybe it's only a small 
wrapper around the really interesting function.
d. Oh, no. It's a fifty-line didding in the message/juggling with 
KIOJobs.
e. OK, let's postpone this until KMHeaders is sane.
f. goto a)

Marc

-- 
Marc Mutz <Marc@Mutz.com>
http://marc.mutz.com/
http://www.mathematik.uni-bielefeld.de/~mmutz/
http://EncryptionHOWTO.sourceforge.net/

_______________________________________________
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]