>>>>> "MR" == Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
I sent the message you're replying to you only, not to this list. You
have turned a private reply of mine public, which I (and I suppose everyone
else) consider to be terribly bad form. Please be more careful about where
you send replies in the future.
MR> Perhaps, I will rephrase my suggestion: refuse to generate a response
MR> based on input from the same "user" more than every five minutes
MR> This implies a queuing system in majordomo.
No it doesn't, unless you want to hold the messages for a specified time or
implement some kind of backoff. If you can come up with a metric that
measures "too many messages too fast", you can store a simple database. I
still say that's overkill for a site which does a bunch of traffic, but
using a database engine might make it reasonable. If the metric comes out
too large, you do EX_TEMPFAIL and let the mail system handle it. Even with
huge queuing times, this makes some sense, provided the metric is tunable
and by default doesn't trigger on normal usage.
MR> It would help the CC:mail no such user meltdown that happens on
MR> occasion though if it were applied to resend as well.
resend is even trickier. If a person replies to, say ten or twenty
messages and they are queued in transit, they will be delivered immediately
which will play havoc with just about any filter system. Besides, resend
already has a front-end filtering system (taboo_*) which majordomo
doesn't. A front-end filter was what I thought we were talking about.
MR> Actually, I'd like to put this logic into the sendmail queuing
MR> function.
That makes more sense, because we decided that if we're going to play with
queuing in Majordomo (most, I recall, didn't want to) then it will be some
ways down the road. At the moment I'm trying to come up with a solution
for 1.95.
MR> I think I skipped over some dicussion about how to go about
MR> "branching" 1.94 in order to start on 2.0. I'd like to suggest CVS 1.8
MR> over SSH as a very good solution.
Well, CVS 1.8 is out of date, I was under the impression that we were
talking about near-term solutions, not 1+ years down the road in 2.0, and
if you're going to submit code, why not by generating a diff? Majordomo
really isn't so huge that you can't submit code changes without CVS. Chan
talked about CVS and I have all of the facilities to implement it, but
nothing's been done so far.
As a postscript, there seems to be a tendency to go off and propose these
elaborate schemes as solutions when what we really need is something that
fits in with the framework we have. It's nice to dream and we should be
taking note of these as things to start to look at once 2.0 is finished or
at least nearing completion, but we aren't nearly to the point where we
have the basis of a framework in which to implement some of these
far-fetched ideas. That's not to say they're bad, but when talking about
real problems it's prudent to discuss "doable" solutions.
- J<
References:
|
|
