Much better mapping of responses to IRC messages

[eevee]

trafficstars

There are, I believe, three major classes of problems here:

1. More or less simple responses, e.g., you send a NAMES and get back NAMREPLY + ENDOFNAMES. The response starts with the first NAMREPLY and ends with the ENDOFNAMES.

2. Compound, complex responses. For example, joining a channel starts with a JOIN, includes a topic response, and finally ends with a names response. So a names response might end both a NAMES or a JOIN. Not too much harder; just have to see who expected to get it first.

3. Super ambiguous responses, such as you might get from... PRIVMSG! The problem is that PRIVMSG doesn't reply on success, so if you use PRIVMSG three times and get back a single error, which message did it correspond to? Also, assuming we want error replies to become exceptions, how long do we wait until we assume success?

   It's possible to guess a lot here, but I'm not sure how much harm the guessing will do, or how much it really matters anyway. Some ideas are:

   • Keep track of how long it generally takes to get replies, and use some reasonable factor of that as a timeout.

   • Gather all the known error replies from all the popular servers and add special-casing for all of them. For example, if we send three messages, only one of them contains IRC formatting, and we get back only one ERR_CANNOTSENDTOCHAN, it's a reasonably safe bet which of them is the culprit.

     Which, of course, brings up another problem: ERR_CANNOTSENDTOCHAN is really meant for when you're banned and can't talk to a channel at all, but inspircd's +c (and I suspect others) reuses the same code to avoid relying on special client support. So how do we distinguish this from being banned, having the first message fail, and then a lag spike? inspircd is kind enough to use a different message, but scraping user-facing error messages sounds like not a great idea...

Zooming out a bit, should yield from client.say() even risk raising an exception in the first place?

More generally, what should happen with unexpected error replies?

What if we must get a particular reply but never do?

Well, wait, I think I can handle that last one. I'm pretty sure the IRC protocol is intended (if not explicitly stated) to send replies in the order the messages were received, with no interleaving. So if we send messages A B C, and we get a reply that could only be for A followed by a reply that could only be for C, we know B just didn't get a response, and/or there's a severe bug somewhere. "Spontaneous" messages like NOTICE can of course happen at any time. (Question: can a PRIVMSG come within a JOIN, before the ENDOFNAMES comes back? I swear I've seen this happen in irssi before, but I don't know if it's the protocol being wacky or irssi just lagging a bit before it shows the names list.)

irc is hard