Well qwerty's already explained why the UnrealIRCd team's understanding of user interaction is wrong, but here's one simple reason for not waiting for the PART response: There's no need to. The original IRC RFC 1459 doesn't even define a response to the PART command so if mIRC waited for it on RFC1459-compliant servers it would never part a channel. Even in RFC 2812 which does define a PART response it also explicitly states that "[the PART] request is always granted by the server". So there's no reason to wait for it. If a user is on a channel and chooses to part then he will always be able to part it. Any server which tries to prevent it is breaching not only every IRC RFC but also fundamental useability.

Which brings us nicely to UnrealIRCd, which does break all those things with the /SHUN oper command - the biggest disgrace to ever appear in an IRC daemon and yet another reason to see UnrealIRCd as nothing more than an excuse for power-hungry kids to play oper and treat an IRC server as their own personal ant farm. /SHUN serves no administrative purpose and is only there for the oper's pleasure, it's the equivalent of pulling off all an insect's legs and watching it try to crawl around.

With all that said, the day I take useability advice from the UnrealIRCd team is the day Hell freezes over and Hitler and Stalin perform the Nutcracker on Ice on the frozen surface of the River Styx. Outlook today: Not so good.


Spelling mistakes, grammatical errors, and stupid comments are intentional.