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

[Brian Stafford <brian stafford uklinux net>]

On Tue, 25 September 10:16 Raven wrote:
> 
> 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.

Even simple procmail files are too complicated.

> And having now
> gotten a glimpse of the sieve language, it does look cleaner.

Yep, and its been subject to peer review as part of the IETF process.
Considerable expertise has gone into its design.

> How about this: Several quarters here seem to be intent on putting built-in
> filtering into balsa.

I see no reason why there should not be a filtering engine in Balsa ...

> I'd much prefer an external program to do the job -

... and external programs have their place too.

I would like to see a world where sieve was embedded into, say, an MTA, an
IMAP server, an MUA and a procmail or fetchmail workalike.  The sieve scripts
would be interchangable between all of these.  A GUIfied sieve editor could be
used to maintain all possible locations for sieve scripts.  Such an editor could
be embedded in Balsa or be a standalone.  (Actually there is an emacs mode
available for editing sieve and there is a web based PHP program to do this
too.)  By venturing down this path we achieve the holy grail of
interoperability.
Promoting the use of ad-hoc systems such as procmail's filters confound the
efforts of those who would promote the use of standards.

> it seems to stay consistent with the Unix/Linux philosophy that way. Let's

Hmmm...using external programs isn't necessarily part of the philosophy.
Its certainly traditional though that tradition started because the PDP-8
original unix only allowed processes up to 8Kb in size.  Realistic programs
had to be broken into many smaller ones.  Traditions are flexible, that
is how they survive.  I don't think anyone nowadays insists that a program
bigger than 8K is too big.  Similarly, I don't think that just because Un*x
allows flexibility with multiple processes it means it is always the best
solution to a problem.

> 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,

No problem there.  I feel very strongly that anything built into balsa should
be sieve.  Its the only standards track filtering language I'm aware of and
being a standard is a very powerful argument for using it.

> and let them choose whether that be procmail,

Well if its external, what they use is none of our business so long as the
external program conforms to balsa's interface to it.

> 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.

Nowt wrong with ./configure --enable- options for this sort of thing.

Brian