Re: new feature ideas

> I'm thinking of adding some new features to SP and thought I'd bounce 
> them off you folks to see if they seem desireable.
> 
> * Add aliases for the various *good commands using ham instead of good.
>    This was actually requested by Karl Fogel.  (so train-ham would do the
>    same thing as train-good for example)

Hm, syntactical sugar. This is not really necessary. ;)

> * Add ability to specify different thresholds for classifying spam/ham.
>    I would allow more than just two levels so that you could put obvious
>    spam into one folder, less obvious spam into another, etc.  I do
>    something like this now using a procmail recipe but its painful that
>    way.  The option would look something like this:
> 
>     spamprobe -o thresholds=0.95:SPAM,0.80:SUSPICIOUS,0.0:GOOD train
> 
>    The decimal number is a score above which the lable that follows it 
> will be printed.  The example above woud have three levels instead of 
> the normal two that SP uses.  These thresholds would only affect the 
> classification printed by SP.  The database related thresholds would 
> still use the defaults.

Yeehaa, this adds a lot of flexibility.

> * Add ability to set the SPAM/GOOD threshold values for training.  I
>    think this would be pretty dangerous so I'm hesitant to actually do
>    this one.

Not sure what the impact would be. Would this really be useful?

> * Add ability to operate in "filter" mode with SP printing the email to
>    stdout with a score and classification added to the Subject: header.
>    SP could also add its own header instead of modifying the Subject.
>    I'm on record as not really liking this feature much but several
>    people have asked for it and it'd be fairly easy to do with the
>    new parser.  This seems fairly dangerous since if SP crashed
>    (hey, it could happen) the email might be lost.  Altering the Subject
>    of the email could be tricky if the Subject header is encoded in an
>    alternative charset then the score would mess that up.

Sounds good. Someone else proposed to decouple spamprobe from its
caller (e.g., procmail) by using an application in the middle which
simply outputs the mail to stdout if spamprobe should crash. This
should do the job.

> * I18N improvements.  I'm toying with the idea of making SP more charset
>    aware.  I'd switch to using wchar_t instead of char and add code for
>    processing each message part in its proper charset.  All terms in the
>    database would be stored in UTF-8.  I'd probably use trigrams for
>    tokens in wide character messages since, from what I've heard, you
>    can't use whitespace as a token delimiter in asian languages.  I'm
>    not sure if there is a lot of interest in having this feature. It
>    would be a big code change runtime memory usage would be impacted
>    significantly.  Ideally I'd make this a compile time option so people
>    who don't ever receive legitimate multi-byte char email would not
>    have to take the memory/performance hit.

This sounds like a rather big change to SP's code. I would leave it
like it is for now and keep that in mind for the (far?) future.

> What do you folks think?  Do these seem like useful ideas?  Anyone else 
> have an interesting idea?  Preferably something that would improve the 
> user interface without requiring major new code.

No other ideas for now. :)


Greetings,
Thomas.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click