Thanks for the patch submission. I'll look at this in greater detail later. "Jonathan Ellis" <[EMAIL PROTECTED]> writes:
> this patch moves the "file store" functionality of FilterParser into > FilterStore, which defines a set of classes that each implement a > contains(self, keys) method. This substantially simplifies firstmatch. I'm currently working on substantial changes to the parsing technology that won't be available for a while, but which separate out each rule type as classes. This allows me to pickle a pre-parsed filter to disk (and to later read it in with no parsing step). However, this won't be available for a while, so cleaning up firstmatch, which has just sort of accreted over time, is a welcome submission. > I also made "-optional" the default (and only) behavior. I see no reason > why any user would want tmda to die because he didn't create a file that he > intends to create later or let auto-append create for him. Jason and I have sort of the opposite philosophy. If you think your filter is actually working and it's not, you should know immediately and more importantly, the email should not be processed until the set of rules you really want to use is in place. A warning in a log file is not sufficient because mail can be lost (assume the rule that should match fails and the next rule that matches drops the mail). If you want to screw yourself that way, we feel you should be explicit. Therefore, errors in the filter processing cause the mail to be deferred until the user fixes the filter. If you want to discuss this further, we'd be more than happy to, but you'll pretty much have to convince us that losing mail because of a filter typo is not really a bad thing. > Finally, I removed the ability to override the from-file action with a > per-line action w/in the file. IMO, these should be grouped in another > file, or in the top-level spec as plain From lines if there are few enough. > I could argue at length why this is a Good Change, but I'll condense it to > an analogy: if we wanted "more than one way to do it" we'd be coding in > perl. I'm in agreement with this change. It simplifies the code, I suspect the feature is rarely used and having separate files for separate actions is nicely self-documenting at the filter file level. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
