Irssi core bugs

Notice: Undefined index: tasklist_type in /var/www/bugs.irssi.org/includes/class.tpl.php(128) : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/bugs.irssi.org/includes/class.tpl.php(128) : eval()'d code on line 90
  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Feature Request
  • Category core
  • Assigned To No-one
  • Operating System Linux
  • Severity Low
  • Priority Normal
  • Reported Version Irssi SVN
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Irssi core bugs
Opened by Wilmer van der Gaast (Wilmer) - 2011-03-27

FS#796 - Parse FLOOD= information from ISUPPORT

Background: 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.

I have a patch to add support for this to irssi. It's pretty simple and will let the user override whatever is in ISUPPORT with what s/he configured for an IRCNet specifically. The info will override irssi-wide limits though.

I'm flooring the time to 10ms, since I remember seeing somewhere that this is the magic "flood me" value. I could be wrong though.

With the little testing I've done, this seems to work well. Of course it may be fully ignorant of irssi coding best practices though. Suggestions for improvement are welcome.

But most of all, are you willing to accept this feature?

This task does not depend on any other tasks.

Wouter Coekaerts (coekie)
Tuesday, 29 March 2011, 20:17 GMT
Makes sense to me.
Jase Thew (bazerka)
Wednesday, 30 March 2011, 08:51 GMT
I'm not sure I agree with this. I don't think we should be adding custom ISUPPORT functionality to support what is basically a local patch to bitlbee, especially given that this can already be easily done via /network add -cmdspeed 0 -cmdmax 9999 bitlbee .
Wilmer van der Gaast (Wilmer)
Wednesday, 30 March 2011, 09:19 GMT
This is not a local patch. This is in bzr and will be in the next release, and if I intended this to be BitlBee-specific I'd just look at IRCNET=BitlBee. This stuff can be much more generic so any IRC network can specify what message rate will trigger their flood detection so IRC clients no longer have to be overly conservative to be on the safe side everywhere.
Jase Thew (bazerka)
Wednesday, 30 March 2011, 10:10 GMT
It would have helped if you stated that it had been committed to bitlbee's repo (I wasn't aware that you're a bitlbee dev) ;) As it has been committed, that pretty much removes my reason for objecting to this request.

I would however like to see this patch respecting the global limits if they've been changed from default.

Edit: Or perhaps the lower of the out of the two values (ISupport vs global)?
Wilmer van der Gaast (Wilmer)
Wednesday, 30 March 2011, 10:24 GMT
D'oh. I now notice that I forgot to include a link to the commit on bugs.bitlbee.org. I really thought it was there. See http://gaa.st/aJ . Sorry about that.

I'll try to adapt my patch to not blindly override global limits either. To clarify, with lower do you mean isupport should be able to make irssi more floody or less floody? And the per-ircnet setting should still "win"?

While you're here BTW, at some point IIRC I'm pretty sure managed to get irssi to send all lines of a flood in one packet. Not anymore now, they're sent one by one, even with a 0ms delay. Not a huge deal but I wonder if I'm on crack and imagined something that the code can't technically do or if I just forgot with what setting it did that. I saw this in tcpdump, so it's also possible that somehow multiple writes once ended up in one packet.
Wilmer van der Gaast (Wilmer)
Monday, 25 April 2011, 22:32 GMT
I wonder if there is a nicer way to check if something is changed from the default than just manually comparing the setting against the default value?

Loading...