I could be high, but it looks like the sequence in Bouncer.py is:
- are we a member? No, return
- do we have previous bounces? No, register it and quit
- is the member disabled? yes, quit
- is the bounce info from today? yes, quit
- is the info stale? yes, clear it out
- start looking for action
It seems like 4) is pretty procrustean. If, for instance, I have a wad of bounces, and decide "screw it, if they get to one bounce, I want them gone" and change the bounce threshold, that's not going to take effect until tomorrow. And besides, that seems like a useful knob to turn (i.e. "how old does the bounce info have to be before I start looking for new ones").
I think maybe the threshold should be checked before the 'check against time', to handle changing thresholds, and that the 'time-to-reexamine' value should be a modifiable value (currently hardcoded 1 day).
Comments?
"DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes:
DM> I could be high, but it looks like the sequence in Bouncer.py
DM> is:
| 1) are we a member? No, return
| 2) do we have previous bounces? No, register it and quit
| 3) is the member disabled? yes, quit
| 4) is the bounce info from today? yes, quit
| 5) is the info stale? yes, clear it out
| 6) start looking for action
DM> It seems like 4) is pretty procrustean. If, for instance, I
DM> have a wad of bounces, and decide "screw it, if they get to
DM> one bounce, I want them gone" and change the bounce threshold,
DM> that's not going to take effect until tomorrow.You have a good point. I think this is best handled by a slight reorg of registerBounce(), so that the check of the bounce score is always done after adjustment of the bounce score. I.e.
are we a member? No, return
do we have previous bounces? No, register it skip to step 7
is the member disabled? yes, quit
is the bounce info from today? yes, don't increment, skip to step 7
is the info stale? yes, reset it and skip to step 7
increment score for today's bounce
is score > threshold? yes, disable 'em.
DM> And besides, that seems like a useful knob to turn (i.e. "how DM> old does the bounce info have to be before I start looking for DM> new ones").
It might be, but I think for now I don't want to add that.
I realized you also want to add a step in cron/disabled that performs a sweep over the currently-bouncing-but-not-yet-disabled members, checking their scores against the threshold. Say this morning the threshold was 4.0 and some member had a score of 3.0. Then I go in and say screw it, set the threshold to 2.0. I'd like today's cron/disabled run to disable all those members with a score of 3.0.
Checking in this stuff to cvs momentarily.
Thanks, -Barry
participants (2)
-
barry＠zope.com -
Dan Mick