* Re: Automatically disabling ERC flood control for BitlBee servers
[not found] <87vcz1bpne.fsf@lw-wireless-pittnet-40-144.wireless.pitt.edu>
@ 2011-03-29 22:25 ` Michael Olson
2011-03-30 15:13 ` Antoine Levitt
0 siblings, 1 reply; 2+ messages in thread
From: Michael Olson @ 2011-03-29 22:25 UTC (permalink / raw
To: ERC Discussion; +Cc: William Gardella, emacs-devel
Sounds interesting. Including the Emacs devels at large. This
"ISUPPORT FLOOD" would likely get stored in erc-server-parameters
after connect. You could hook into 'erc-server-005-functions and use
it to set erc-flood-protect (as a buffer-specific value tied to the
buffer of the process connected to the bitlbee server). Then possibly
disable flood protection toggling in that case.
On Tue, Mar 29, 2011 at 2:08 PM, William Gardella <gardellawg@gmail.com> wrote:
> Hello all,
>
> wilmer, the author of BitlBee ( http://bitlbee.org/ ), the notorious
> instant messaging to IRC gateway, is attempting to get a good
> cross-section of IRC clients to support automatically disabling their
> rate limiting features when connected to a BitlBee server. Rate
> limiting is counterproductive when used with BitlBee; it gets in the way
> of BitlBee's paste buffering feature, which is used to convert a series
> of lines entered in rapid succession (e.g. a paste into the IRC client)
> into a single, multi-line instant message at the other end. Flood
> control makes the pasted text dribble in over several seconds, instead
> of cooperating nicely with BitlBee's paste buffer.
>
> For the moment, the kludge I use in ERC for BitlBee is to disable flood
> control before attempting to send multiple lines yanked from another
> buffer, or toggling flood control off with a buffer local variable.
> However, wilmer would like to see clients support ISUPPORT FLOOD
> information from the server, so that clients connected to bitlbee
> automatically know that they should disable their rate limiting. See
> http://bugs.irssi.org/index.php?do=details&task_id=796 for the
> implementation he's trying to get the irssi people to use:
>
>> BitlBee doesn't care about message floods at all
>> and in fact it's good if the IRC client does *not* rate limit
>> pastes so they can be converted to multiline messages on the
>> IM side. ATM it takes some effort to configure one's
>> well-behaved IRC client to be willing to flood BitlBee.
>>
>> To make this easier, I added a little piece of info to
>> BitlBee's 005:
>>
>> :localhost 005 wilmer ... FLOOD=0/9999 :are supported by this
>> server
>>
>> The format is FLOOD=cmd_queue_speed/max_cmds_at_once. One
>> would maybe consider this rather biased against irssi's
>> implementation of rate limiting but it seems generic to me.
>
> How easy would this be to implement in ERC? Where would one start?
>
> Best,
>
> --
> William Gardella
> J.D. Candidate
> Class of 2011, University of Pittsburgh School of Law
>
>
> _______________________________________________
> Erc-discuss mailing list
> Erc-discuss@gnu.org
> http://lists.gnu.org/mailman/listinfo/erc-discuss
>
--
Michael Olson | http://mwolson.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Automatically disabling ERC flood control for BitlBee servers
2011-03-29 22:25 ` Automatically disabling ERC flood control for BitlBee servers Michael Olson
@ 2011-03-30 15:13 ` Antoine Levitt
0 siblings, 0 replies; 2+ messages in thread
From: Antoine Levitt @ 2011-03-30 15:13 UTC (permalink / raw
To: emacs-devel; +Cc: erc-discuss
30/03/11 00:25, Michael Olson
> Sounds interesting. Including the Emacs devels at large. This
> "ISUPPORT FLOOD" would likely get stored in erc-server-parameters
> after connect. You could hook into 'erc-server-005-functions and use
> it to set erc-flood-protect (as a buffer-specific value tied to the
> buffer of the process connected to the bitlbee server). Then possibly
> disable flood protection toggling in that case.
>
> On Tue, Mar 29, 2011 at 2:08 PM, William Gardella <gardellawg@gmail.com> wrote:
>> Hello all,
>>
>> wilmer, the author of BitlBee ( http://bitlbee.org/ ), the notorious
>> instant messaging to IRC gateway, is attempting to get a good
>> cross-section of IRC clients to support automatically disabling their
>> rate limiting features when connected to a BitlBee server. Rate
>> limiting is counterproductive when used with BitlBee; it gets in the way
>> of BitlBee's paste buffering feature, which is used to convert a series
>> of lines entered in rapid succession (e.g. a paste into the IRC client)
>> into a single, multi-line instant message at the other end. Flood
>> control makes the pasted text dribble in over several seconds, instead
>> of cooperating nicely with BitlBee's paste buffer.
>>
>> For the moment, the kludge I use in ERC for BitlBee is to disable flood
>> control before attempting to send multiple lines yanked from another
>> buffer, or toggling flood control off with a buffer local variable.
>> However, wilmer would like to see clients support ISUPPORT FLOOD
>> information from the server, so that clients connected to bitlbee
>> automatically know that they should disable their rate limiting. See
>> http://bugs.irssi.org/index.php?do=details&task_id=796 for the
>> implementation he's trying to get the irssi people to use:
>>
>>> BitlBee doesn't care about message floods at all
>>> and in fact it's good if the IRC client does *not* rate limit
>>> pastes so they can be converted to multiline messages on the
>>> IM side. ATM it takes some effort to configure one's
>>> well-behaved IRC client to be willing to flood BitlBee.
>>>
>>> To make this easier, I added a little piece of info to
>>> BitlBee's 005:
>>>
>>> :localhost 005 wilmer ... FLOOD=0/9999 :are supported by this
>>> server
>>>
>>> The format is FLOOD=cmd_queue_speed/max_cmds_at_once. One
>>> would maybe consider this rather biased against irssi's
>>> implementation of rate limiting but it seems generic to me.
That seems like a nice feature to have, and the FLOOD option is indeed
parsed into erc-server-parameters. But then as was pointed out the
settings are pretty irssi-specific (and I don't really understand the
irssi documentation). Why not use the settings from
http://www.faqs.org/rfcs/rfc2813.html instead, overriding the 10 and 2
seconds? (it's the way it's implemented in emacs, and likely to be the
way it's implemented in other clients). As it is, it's hard to figure
out how to act on those variables without rewriting the flood control
algorithm.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-03-30 15:13 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87vcz1bpne.fsf@lw-wireless-pittnet-40-144.wireless.pitt.edu>
2011-03-29 22:25 ` Automatically disabling ERC flood control for BitlBee servers Michael Olson
2011-03-30 15:13 ` Antoine Levitt
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.