Re: Fwd: [ANNOUNCE] : Filters patch against 1.2.0 [e.allaud@wanadoo.fr]

[Raven <dmstowell ameritech net>]

On 2001.09.25 02:35 Brian Stafford wrote:
> The [procmail] filter rules are unreadable once you've forgotten
> what they do.  Its source code is equally unreadable - it actually looks
like
> it was deliberately made unreadable, who knows?  Although the program
serves
> a useful purpose, the implementation is unbelievably ugly.  I have always
taken
> the view that if code is clearly written and neatly laid out then it will
> have been thought through properly and will be easy to maintain.  If the
code
> is untidy then its likely to be buggy too.  Nothing in my programming
> experience has ever broken this rule.

Okay, I'll have to admit that my .procmailrc files are rather simple, with
no nesting, forwarding, or other such to complicate matters. And having now
gotten a glimpse of the sieve language, it does look cleaner. I've not
looked at procmail's source code, so I'll have to take your word for it on
that point. But I agree with your point about neatly written code
completely.

How about this: Several quarters here seem to be intent on putting built-in
filtering into balsa. I'd much prefer an external program to do the job -
it seems to stay consistent with the Unix/Linux philosophy that way. Let's
make it user configurable - go ahead and put built-in filters into the
program, but give the user a choice between using that system and using an
outside agent, and let them choose whether that be procmail, sieve, or
something else. Whould that work? You could even choose whether or not to
compile in built-in filtering, if you want to pare down your executable.

Raven
------------------------------------------------------------
Raven (not the OTHER Raven, THAT Raven! :-)
<dmstowell@ameritech.net>

And if love remains
Though everything is lost
We will pay the price
But we will not count the cost