On Apr 3, 2006, at 5:49 AM, A. Pagaltzis wrote:
* Peter da Silva <[email protected]> [2006-03-21 13:55]:
I have forever meant to write my own mail filter script and
retire that nasty paleolithic excuse for a hack...
Heh.
I wrote one, then replaced it with a script to turn my simpler
and more understandable syntax into a procmailrc, after running
into one too many variant mail tentacles.
But I'll support you to the fullest when you get a Tuit or two.
Even after I tell you that I planned to have the filter be
written in Perl? :-)
Then it'll have the same problem as procmail and sieve.
I’m just very tired of little languages.
Filter rules shouldn't be a general purpose language except as an
exception. They should be something you can put in a relational
database without running any of them as code except in extreme cases.
Given that the script is still Perl however
would mean that playing fancy tricks would be possible without
pointlessly wasting effort – first to figure out the limitations
of yet another arbitrarily limited crappy mini-language, then to
find ways around them.
Perl *is* "another arbitrarily limited crappy mini-language".
Any match in a [mailbox] section goes to that mailbox.
Mmm, I was thinking about something along similar lines, only
with a Real Syntax by virtue of it being a DSL.
Real Syntax is a limitation. Once you have hundreds of rules keeping
them straight becomes a nightmare.
How do you say
SELECT UNIQUE r.mailbox,m.match FROM rules r,matches m
WHERE r.rule_set = m.rule_set AND m.header='From' AND
m.match_type=EXACT;
when your rules are in Perl?
Think about this:
CREATE TABLE matches (
rule_set INTEGER,
header VARCHAR,
match_type INTEGER,
match VARCHAR
);
CREATE TABLE rules (
rule_set INTEGER,
mailbox VARCHAR,
rule_type INTEGER,
script VARCHAR
);
Then you can perform fast relational lookups on the match table, and
you only need scripts for exceptions.
