From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.devel,gmane.emacs.erc.general Subject: Re: Automatically disabling ERC flood control for BitlBee servers Date: Wed, 30 Mar 2011 17:13:46 +0200 Message-ID: <871v1ohc9h.fsf@gmail.com> References: <87vcz1bpne.fsf@lw-wireless-pittnet-40-144.wireless.pitt.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1301498078 9392 80.91.229.12 (30 Mar 2011 15:14:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2011 15:14:38 +0000 (UTC) Cc: erc-discuss@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 30 17:14:35 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4x6M-0005ke-SN for ged-emacs-devel@m.gmane.org; Wed, 30 Mar 2011 17:14:31 +0200 Original-Received: from localhost ([127.0.0.1]:49824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4x6M-0005xR-3I for ged-emacs-devel@m.gmane.org; Wed, 30 Mar 2011 11:14:30 -0400 Original-Received: from [140.186.70.92] (port=49745 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4x6C-0005vE-8a for emacs-devel@gnu.org; Wed, 30 Mar 2011 11:14:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4x6A-0001Wq-5I for emacs-devel@gnu.org; Wed, 30 Mar 2011 11:14:20 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:57326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4x69-0001WG-Rt for emacs-devel@gnu.org; Wed, 30 Mar 2011 11:14:18 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q4x67-0005eA-VP for emacs-devel@gnu.org; Wed, 30 Mar 2011 17:14:15 +0200 Original-Received: from portable50.ceremade.dauphine.fr ([193.48.71.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2011 17:14:15 +0200 Original-Received: from antoine.levitt by portable50.ceremade.dauphine.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2011 17:14:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 56 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: portable50.ceremade.dauphine.fr User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137918 gmane.emacs.erc.general:1317 Archived-At: 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 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.