Next: Adressbook (ADB) classes
Up: The Real Hackers' Guide
Previous: Shortcomings and things to
  Contents
The following proposal is currently being implemented in source.
Filtering rules in Mahogany are described in a simple control language, interpreted
by a recursive descent parser. No yacc or flex required. I try to explain this
in some form of BNF notation:
RULE:
CONDITION EXPRESSION EXPRESSION
// if true // if false
CONDITION:
( CONDITION LOGICAL_OPERATOR CONDITION )
SIMPLE_CONDITION
EXPRESSION:
ACTION_COMMAND
RULE
SIMPLE_CONDITION:
match_exact(arg, flags)
match_substring(arg, flags)
match_regexp(arg, flags)
python_rule(pythonfunc, args)
...
ACTION_COMMAND:
move_to_folder()
delete()
adjust_score() // I'd like scoring of messages like in GNUS, useful for news
print()
forward_to()
send_reply()
python_acton(pythonfunc, argc)
...
I believe this would be:
- easy to parse by the program
- easy to understand and edit by humans as it is stored in a programming-language
like style
- easily extensible
- powerful enough to build rather complex expressions and rules
A Filter object would be an abstract representation of a set of rules parsed
from a string (can contain more than one rule). It might be used by applying
it to a given Message object. A subset of the Filter functionality could be
a MatchTest object, which only knows conditions but no rules. It would return
true if its conditions all return true (includin possible logical operators
of course), false otherwise. It is used by the Filter class and could be used
by some other Mahogany functionality like e.g. a "vacation"
function which needs to check for mail-loops. Though, all this can actually
be achieved with Filters, there shouldn't really be a need for a MatchTest class.
Next: Adressbook (ADB) classes
Up: The Real Hackers' Guide
Previous: Shortcomings and things to
  Contents
Charlie &
2001-04-19