Re: Automatically disabling ERC flood control for BitlBee servers

Re: Automatically disabling ERC flood control for BitlBee servers

[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.
>
> 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/

Re: Automatically disabling ERC flood control for BitlBee servers

[Antoine Levitt]

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.