Version: 0.19+ Build 3102 (using KDE Devel) Installed from: Compiled sources Compiler: gcc version 3.4.4 OS: Linux When selecting multiply users in the nicklist and changing modes on them for every nick one mode-line gets sent. It would be better to look how many modes the server can handle in one line and send them together. This would save some bandwidth and not block the queue. For example giving voice to 12 users now takes 12 lines (and you'll wait very looong) but could be sent in just two lines on ircu. RPL_ISUPPORT is documented here: http://www.faqs.org/ftp/pub/pub/internet-drafts/draft-brocklesby-irc-isupport-03.txt Thanks! ;-)
Sounds good.
Created attachment 33683 [details] respect RPL_ISUPPORT "MODES" just created a patch for it against trunk, revision 967885.
This look good. I'm going to remove the support for an unlimited MODES (i.e. setModesCount(100)), however: A message operating on so many nicks would likely go beyond the 512 byte buffer limit imposed on a single IRC message, and thus get cut off and lose self-consistency. Granted, this is a far-fetched scenario because there's probably no ircd out there that sends MODES without a value, and people are unlikely to set a mode on 100 people at once, but let's not be content with creating bugs we know about. IOW, a proper implementation of unlimited MODES would need to be aware of the buffer limit and send only that much at once as can fit into a single IRC message. However, this patch is useful without support for that, so I'm going to merge a 3-or-what-the-server-tells-us version of it (shifting the blame to the server if it's too high a value).
SVN commit 968389 by hein: Add partial support for MODES in RPL_ISUPPORT. Patch by Sebastian Wiedenroth (thanks!) with some mangling by me. CCBUG:126224 M +8 -0 ChangeLog M +26 -12 src/irc/channel.cpp M +10 -0 src/irc/inputfilter.cpp M +12 -0 src/irc/server.cpp M +4 -0 src/irc/server.h WebSVN link: http://websvn.kde.org/?view=rev&revision=968389
> so I'm going > to merge a 3-or-what-the-server-tells-us version of it (shifting the blame to > the server if it's too high a value). Is that behaviour changed yet (not checking the buffer length)? If not you really should, because blaming it on the server is pretty useless here (as it makes no sense for the server to know how long your submitted names are). The server only OFFERS you to submit up to e.g. 10 nicks if they fit into your line - it doesn't tell you that you MUST do it in all cases without taking the maximum message length into consideration anymore. It only tells you that it'd be able to handle as much as those 10 nicks if, and ONLY if that results in a valid, complete mode event command in your very specific case.
> Is that behaviour changed yet Nope.
Created attachment 47884 [details] patch for respecting line length properly I implemented that behaviour now. I attached a patch file that will alter channel.cpp accordingly. Konversation should then only use as many mode parameters as can be possibly sent without exceeding the line length or risking the resulting MODE event getting truncated (taking the prepended host mask for the event message into account).