next up previous contents
Next: Adressbook (ADB) classes Up: The Real Hackers' Guide Previous: Shortcomings and things to   Contents

Filtering

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:

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 up previous contents
Next: Adressbook (ADB) classes Up: The Real Hackers' Guide Previous: Shortcomings and things to   Contents
Charlie & 2001-04-19