Summary: | Disable auto-WHO for Twitch servers. | ||
---|---|---|---|
Product: | [Applications] konversation | Reporter: | Chiitoo <escomk3> |
Component: | general | Assignee: | Konversation Developers <konversation-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hein, j.k |
Priority: | NOR | ||
Version: | 1.5.1 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/konversation/e4085aed8e38b9d665aa1efd1c38fb0cfe593da7 | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: | Patch to Disable Auto-WHO for Twitch |
The main thing that's wrong here is that it's just not reasonable to include a check for a particular server hostname to alter behavior :). I understand the problem, but we're going to have to come up with a better idea for a solution here. Indeed. The patch is after all only a result (and I guess a personal 'fix') of me hacking around, trying to see if I can even find where the WHO comes from in the first place. I fully expected this not to be 'the fix' but that there would be a more proper way to do it. Thanks for the comment! So we get a 421 for the failing WHO from the Twitch server it turns out. I think we should catch it, and stop auto-WHO'ing in response. I think it's safe to assume that if you get a 421 the server won't start supporting the command within the same session, and it's pointless to keep trying then. (In reply to Eike Hein from comment #3) > So we get a 421 for the failing WHO from the Twitch server it turns out. I > think we should catch it, and stop auto-WHO'ing in response. I think it's > safe to assume that if you get a 421 the server won't start supporting the > command within the same session, and it's pointless to keep trying then. Seems like a plan. I have been thinking of this issue now and then again, and have been meaning to see if I could come up with a more proper-like solution. Unfortunately, I haven't managed to get to it yet. Many thanks for the comment (and reminder). :] Just chiming in here because i ran into this issue. The above patch/hack didn't apply cleanly for me (source RPM from OpenSUSE 15.1), and i had to switch out the != check for an .endsWith("twitch.tv") call as for a more general solution, my immediate idea was that, during connecting to a server there seems to be this step that says "checking the capabilities of the server", could this be adapted to check the twitch-specific protocol extensions/omissions and set a flag whether WHO is an accepted command? then that (and a few other things) could be guarded by this flag? Could be, if the Twitch server announces some sort of cap bit related to this. Git commit e4085aed8e38b9d665aa1efd1c38fb0cfe593da7 by Peter Simonsson. Committed on 27/10/2019 at 12:39. Pushed by psn into branch 'master'. Disable WHO requests for twitch.tv servers twitch.tv's IRC servers doesn't have support for the WHO command so let's disable all WHO requests for servers that requests twitch.tv capabilities M +3 -0 src/irc/channel.cpp M +20 -2 src/irc/server.cpp M +3 -0 src/irc/server.h https://commits.kde.org/konversation/e4085aed8e38b9d665aa1efd1c38fb0cfe593da7 Many thanks for taking care of this! |
Created attachment 89498 [details] Patch to Disable Auto-WHO for Twitch Teegrins! Twitch (irc.twitch.tv) does not support many (most?) of the common IRC commands, WHO being one of them. As such, the automagical WHO-command results into a "WHO: Unknown command." message every minute, which can get quite annoying. I realise that this is definitely not the most common use for Konversation, or that it might even be beyond its intended use, but I can't imagine mending this having negative aspects to it. The attached patch is something I managed put together to further demonstrate what I'm asking for, but being a true beginner what comes to code, it could very well break something, or be all kinds of wrong without me knowing! From what I can tell, it has been working fine here on (x86_64) Gentoo. Thanks!