Drew Raines <[EMAIL PROTECTED]> writes: > Using Python source for .tmda/config was brilliant. It's simple > enough for the guy who just wants to set a couple of variables, and > as complex as someone who knows what they're doing wants it to be. > Why not carry that philosophy over into the filter side of TMDA > where things get more complex?
I wrote the initial FilterParser (before Tim got ahold of it and turned it into the FilterParser on 'roids it is now), so it's my fault if using a simple proprietary syntax instead of Python was a bad decision. The reason I did this is precisely because as you said, things are more complex on the filter side of TMDA. I was hesitant to make it as complicated as say maildrop or procmail, where the bulk of the support lists are questions on filter syntax and usage. In .tmda/config this isn't much of a problem, since everything can be done with easy to understand VARIABLE = VALUE pairs. Even so, we still field Python syntax questions and mistakes on -users. It's hard to say whether this will increase exponentially if the filters become Python programs as well. > Learning entry-level Python skills isn't any more difficult than > FilterParser, for the average TMDA user. I'm not sure I agree with you here. I think the line-by-line <source> <match> <action> format of a filter file is quite easy even for a non-programmer to understand. > I just want to stir discussion to make sure we don't pass up a valid > design suggestion. I agree that this is an attractive proposition. I'd like to see what Tim thinks about these issues, and particularly Gre7g's suggestion of providing a Python interface in addition to a simple syntax interface. Tim reads CS textbooks on parsing and stuff for fun. :-) _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
