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

List:       kmail-devel
Subject:    Re: KMail Filter Idea
From:       "Dr. Sergio Mujica" <sergio.mujica () terra ! cl>
Date:       2000-12-29 6:16:04
[Download RAW message or body]

On Thursday 28 December 2000 17:34, Jason Stephenson wrote:
> Yeah, you're probably right which is why I said I'll send out a patch in
> April or so. I wasn't actually planning on adding this to the main source
> tree. There have been a few people asking for something like this on the
> list, though, and it is something that I want. (i have some code for
> automagically detecting spam, and I'd like to add it to KMail.)
>
Jason, just remember that perl is better than nothing. We would all like to 
have the ability you mention. I'd also like to be able to use the anti 
spamming code!  An SPP (Small Perl Program) solves many problems, quickly... 
it is just that Perl is kind of ugly, one would say a WORN (Write Once Read 
Never) language. Please... I do not want to start a religious war here, just 
my own personal, humble opinion.

> This sort of thing *might* be handled better by the MTA, rather than the
> MUA. It has been said, though that KMail and KDE are aimed at "end users"
> or people who aren't all that computer savvy, so something like this would
> be more useful to them if it were in the MUA. (I also seriously doubt that
> KDE is really used by all that many people who qualify as beginners. I
> imagine the majority of our users are people who are already comfortable
> with UNIX and would have no problems setting up fetchmail, procmail,
> sendmail, or exim to handle mail filtering for them.)

If a user is going to write code to filter his/her own mail, I would say that 
is a rather computer savvy user.  Procmail would be more useful in a native 
unix mail environment. However many people around use kmail to read POP mail. 
In this case it seems better suited to the job to have a nice filtering tool 
to process mail downloaded form a POP server. Therefore the MUA would be a 
better place than the MTA. In any case nothing prevents us from having both. 
Fetchmail and procmail at the MTA, and kmail filtering at the MUA.

>
> Perhaps, rather than stealing the filter language from another product, we
> could make KMail play nice with procmail or something? Perhaps we could
> have a module interface, or use DCOP, so that folks could add their own
> filtering tools?
>
> When I mentioned Perl in the previous post, I was really thinking of other
> languages, too. Python and Perl would be easy to add. Once JavaScript gets
> up to snuff with KDE, that would be easy to use to script filters as well.
>
If some filtering language is added such us a python or  perl or whatever, it 
may be necessary to have a message header parser function. Also we would need 
a programmer's interface to the common messaging  functions offered by kmail.
For instance, a function to transfer a message to a folder that can be called 
from the language one is using. 

Are we talking of something like extending and building on the "filter app" 
option we got now?

> As for rewriting KMail, that was a suggestion that I had. Some parts of it
> could stand major revision. I'd be all too happy to fork the KMail
> development into another application if everyone else is happy with how
> KMail works now. I'm personally happy with most of what KMail does from a

Everyone I know is happy with kmail !!! ;-)

> user perspective and there are a few things I'd like to add, such as better
> mail filtering and a better address book interface. (No, KAB doesn't cut
> it, either.)
>
> As a programmer, I see that some bits of the KMail codebase could use a few
> nips and tucks, and maybe a complete rewrite here or there. Some cruftiness
> has seaped in over the years.
>
> On Thursday 28 December 2000 12:07, Guillaume Laurent wrote:
> > On Thursday 28 December 2000 17:48, Dr. Sergio Mujica wrote:
> > > Is there a way to allow the user to choose a language, perharps at
> > > build time? I would much rather have embedded guile than perl.  It so
> > > much morepleasant to write scheme that to write perl.
> >
> > I'm already cringing at the idea of a full kmail rewrite (isn't that a
> > bit overkill ?), but a dynamically loadable filter language... Come on,
> > really.
> >
> > I'd wage that less than 10% of the people currently using kmail are
> > reaching the limits of the current filtering facilities. An embedded
> > language will be used by 0.1%.
>
> _______________________________________________
> Kmail Developers mailing list
> Kmail@master.kde.org
> http://master.kde.org/mailman/listinfo/kmail

-- 
atte. -sm
_______________________________________________
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]