* 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.