New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
general all-purpose flood control #252
Comments
Also related to #236. |
This could either be a pure duplicate of #159 or we could intercept all calls to Since we don't wanna break things, we could give |
Flood control should be module specific. There are times when information
should not be suppressed by an automatic filter, but rather, left to the
discretion of the module.
A solution to #159 should be adequate to address the issue.
…On Wed, 27 Dec 2017, 01:53 Robin Richtsfeld, ***@***.***> wrote:
This could either be a pure duplicate of #159
<#159> or we could intercept all
calls to phenny.msg and thus have a "general all-purpose flood control".
The latter doesn't seem quite right, thou.
Since we don't wanna break things, we could give phenny.msg a defaulted
parameter to indicate if flood control should be applied or if the calling
side knowns what it's doing.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#252 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AB-Xl24gqtvyMbnSrgnA2R7wCwPTWuvsks5tEZTzgaJpZM4Op_Mr>
.
|
What issue is this a duplicate of? |
See the last two comments. |
Some modules (mailing list, commit messages, etc.) when they get behind might try to post dozens of updates at a time. These end up more or less flooding a channel. In these cases, it should post at most three messages: e.g., the earliest update, a message that says "...", and the latest update.
The text was updated successfully, but these errors were encountered: