From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Olson Newsgroups: gmane.emacs.erc.general,gmane.emacs.devel Subject: Re: Automatically disabling ERC flood control for BitlBee servers Date: Tue, 29 Mar 2011 15:25:43 -0700 Message-ID: References: <87vcz1bpne.fsf@lw-wireless-pittnet-40-144.wireless.pitt.edu> Reply-To: ERC Discussion NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1301437908 25120 80.91.229.12 (29 Mar 2011 22:31:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Mar 2011 22:31:48 +0000 (UTC) Cc: William Gardella , emacs-devel@gnu.org To: ERC Discussion Original-X-From: erc-discuss-bounces+sf-erc-help=m.gmane.org@gnu.org Wed Mar 30 00:31:43 2011 Return-path: Envelope-to: sf-erc-help@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 1Q4hRs-0001Am-J6 for sf-erc-help@m.gmane.org; Wed, 30 Mar 2011 00:31:40 +0200 Original-Received: from localhost ([127.0.0.1]:36254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4hRr-0002QV-L3 for sf-erc-help@m.gmane.org; Tue, 29 Mar 2011 18:31:39 -0400 Original-Received: from [140.186.70.92] (port=60193 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4hMW-0000Lc-AZ for erc-discuss@gnu.org; Tue, 29 Mar 2011 18:26:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4hMU-0004rS-PF for erc-discuss@gnu.org; Tue, 29 Mar 2011 18:26:08 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:33512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4hMU-0004qb-KO; Tue, 29 Mar 2011 18:26:06 -0400 Original-Received: by iyf13 with SMTP id 13so792519iyf.0 for ; Tue, 29 Mar 2011 15:26:05 -0700 (PDT) Original-Received: by 10.231.113.86 with SMTP id z22mr490244ibp.93.1301437563119; Tue, 29 Mar 2011 15:26:03 -0700 (PDT) Original-Received: by 10.231.35.196 with HTTP; Tue, 29 Mar 2011 15:25:43 -0700 (PDT) X-Originating-IP: [216.103.134.130] In-Reply-To: <87vcz1bpne.fsf@lw-wireless-pittnet-40-144.wireless.pitt.edu> X-Google-Sender-Auth: BRO_XuxFeJ0bhj7diUSmZVTXZZ0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: erc-discuss@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ERC Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: erc-discuss-bounces+sf-erc-help=m.gmane.org@gnu.org Errors-To: erc-discuss-bounces+sf-erc-help=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.erc.general:1316 gmane.emacs.devel:137881 Archived-At: 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 wr= ote: > 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. =C2=A0Rate > 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. =C2=A0Flood > 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. =C2=A0Se= e > http://bugs.irssi.org/index.php?do=3Ddetails&task_id=3D796 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=3D0/9999 :are supported by this >> server >> >> The format is FLOOD=3Dcmd_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? =C2=A0Where 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 > --=20 Michael Olson=C2=A0 |=C2=A0 http://mwolson.org/