Re: Filtering

[Mikael Hermansson <mikeh bahnhof se>]

I fully agree on this. Almost every Linux system already has procmail 
installed on they'r boxes.

Greats

MikeH

On Tue, 25 Jan 2000 21:09:09 Jules Bean wrote:
> On Tue, 25 Jan 2000, Jeffrey Stedfast wrote:
> 
> > 
> > I would personally rather see Balsa not depend on procmail for filtering
> > while it may be the "easy way" I don't think it'd be the "best way"
> 
> Why not?
> 
> > having to "shell out" costs more in resources than it would having it's 
own
> > filtering capabilities. 
> 
> Absolute rubbish.
> 
> > However, being able to read procmail config options
> > might be a good idea as many people do use procmail and are already
> > familiar with it's setup.
> 
> True.
> 
> Now, excuse me for being antagonistic, but those were not informed
> arguments :-)
> 
> One program, one job, is the unix way.  And not without reason.  For
> example: if everyone who wants to filter mail --- not just balsa users ---
> uses procmail, then procmail will become enhanced with all the features
> people want.
> 
> Having to 'shell out' costs virtually nothing. Also, procmail does the
> filtering at the 'logical' time - at mail delivery time, not at MUA load
> time.  If, for example, you haven't checked your email in a few days and
> have 1000 messages in your inbox to filter, that'll take a while.  With
> procmail, it's already filtered.
> 
> All that having been said, there are a few arguments for filtering
> built-in to balsa:
> 
> Procmail's config files are genuinely unnecessarily opaque in design.  It
> is possible to have power without being that opaque :-)
> 
> Having the filtering in-balsa is more flexible for the case that your
> messages are physically distributed on a variety of systems -- in the
> procmail case, you'd need procmailrc's in every place
> 
> Having the filtering in-balsa allows better integration with balsa's other
> facilities, and would allow for some quite cool 'wizards' watching your
> normal mail-moving habits and guessing filtering rules.
> 
> 
> *however*
> 
> it's going to be hard to put a GUI onto a properly powerful filtering
> engine.  Intuitive GUIs for what are essentially procedural tasks are not
> properly understood.
> 
> Camel is on its way, and camel's vfolder stuff will sort-of supercede
> filtering, and camel will have some filtering capability built-in.
> 
> 
> All of which having been said: if someone wants to code filtering, do it.
> Just think about the above issues first!
> 
> Jules
>  
> /----------------+-------------------------------+---------------------\
> |  Jelibean aka  | jules@jellybean.co.uk         |  6 Evelyn Rd	       |
> |  Jules aka     | jules@debian.org              |  Richmond, Surrey   |
> |  Julian Bean   | jmlb2@hermes.cam.ac.uk        |  TW9 2TF *UK*       |
> +----------------+-------------------------------+---------------------+
> |  War doesn't demonstrate who's right... just who's left.             |
> |  When privacy is outlawed... only the outlaws have privacy.          |
> \----------------------------------------------------------------------/
> 
> 
> -- 
> 	FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail balsa-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.