On Mar 17, 2014, at 02:34 PM, Stephen J. Turnbull wrote: >I don't understand what you're trying to say here. Are you saying >that rules should not have a "rules_to_run_before_this_rule" field, >but it's OK if a chain "rule_B, rule_A" is buggy because rule_A should >be run before rule_B? Of course we should then fix the bug -- the >point is that it is currently very easy for such bugs to occur, >because rules may depend on metadata, and set/change metadata.
I know you remember these diagrams: :) http://pythonhosted.org//mailman/src/mailman/docs/8-miles-high.html#basic-messaging-handling-workflow >Perhaps rules should be allowed to add new metadata, but not change >existing metadata? > >I think I already mentioned that I have a difficulty with the concept >of "*pure* Boolean with side effects", too. :-) I was being sloppy in my previous response. Rules either hit or miss. Their check() method is called and it must return True or False. They cannot depend on any other rule having been run before or after them, i.e. they are self-contained. The check() method gets a mailing list object, the message, and a metadata dictionary. Rules must not have a side-effect on either the mailing list or the message. They may have a side-effect on the metadata dictionary, but as you say above, they may only add new metadata, not delete or change existing metadata. They also can't refer to metadata from other rules, because you don't know what order rules are run in. After a message is accepted (and processed) by the LMTP server, it is dropped into the `incoming` queue. The incoming queue runner picks the message up and processes messages through a chain. By default this is the `default-posting-chain`. This chain is composed of list of rules and actions (parlance, a 'chain of links'). Each link in the chain contains a rule, an action, and a target. If the rule hits, the action is taken. If the rule misses, the next link in the chain is processed. Actions can be all kinds of things (see the interface for details), but it is often 'defer', which more or less acts like a rule miss in that the next link in the chain is processed. (The difference is that the chain processing infrastructure records which rules hit and which rules miss. In the default processing chain, there is an `any` rule which looks at the metadata recorded by the processing infrastructure, and *it* takes a `jump` action if any of the deferred rules have hit.) (Please note that this logic is embodied in the built-in chain, which by default is the chain that the incoming queue runner processes. Other chains do not usually have links of rules since their functionality is much simpler. E.g. the discard chain just writes a log message, fires an event, and exits, thus throwing away the message.) >N.B. As far as *I* am concerned, you can take your time about >responding to this. I need to go review the docs and code on all this >anyway. But I suspect that if *I'm* confused about these concepts, >*others* may be too, and they're pretty fundamental to customizing and >extending Mailman 3. Pictures help a lot here! :) If you want to see where the metadata added by the member and nonmember moderation rules gets used, look at the moderation chain. If either of those two rules hit, then processing jumps to the moderation chain. All the moderation chain does though is dispatch to some other chain (in parlance, it jumps to some other chain). Which chain it jumps to depends on the metadata written by one of those two rules, specifically the 'moderation_action'. This piece of metadata corresponds directly to the action that should be taken when a particular person posts to the mailing list. So if stephen@ posts and is a member and has an action of `discard`, then the moderation chain jumps to the discard chain described above. Let's make sure we have a whiteboard at Pycon. :) Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9