Forums Bug Reports Assuming PART is always successful

I've never seen a failure.

I have however seen delays and message leaking into the Status Window.

All in all though, I'm quite happy for the current behaviour to stay. The occurences of such message leaks are rare (I've seen it twice in the past, what, 11 years?).

This logic is so flawed it amazes me it came from a developer (even an unrealircd one)... When Word gives you a chance to save your documents or mirc asks confirmation to exit, the GUI is being completely responsive. The window doesn't close but another event happens immediately instead: a warning box pops up, informing the user what's going on and asking for further action. This is very different from delaying an action, giving no indication to the user that mirc is waiting for something before it closes the window. To make the distinction even clearer, consider the aforementioned example of mirc asking for confirmation to exit. If the user clicks OK on the confirm dialog box, mirc exits immediately (or almost immediately), ie it doesn't wait for the server to tell it "ok, I acknowledged your quit" before it closes its window. See the difference? Confirmation dialogs have nothing to do with UI responsiveness.

However the above was just to illustrate why confirmation dialogs are a terrible analogy. The actual (and rather perplexing to me) issue is that some people seem to actually prefer experiencing obscure delays in window closing that may last quite a while, depending on network conditions etc. And for what purpose? Does the idea that a channel window might be closed a little while before the client receives the PART reply shock them that much?

I've seen that myself, but I always credited that to lag altho I'm not really sure why it happened. I would quit and a bit later I would see quit messages for nicks that aren't on any common channels but were on the channel I parted. But as you said, in my 10-11 years I've oly seen it less than a handful of times.

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.

I do feel this is important, because it is the way parts were meant to work... In the event a part is denied, a user would be unable to reopen the window (the server would deny the join, because the user would already be on that channel)

How can it be the way PARTs were meant to work? PARTs were never meant to be disallowable! And as far as I'm aware the only IRC daemon that attempts to prevent a PART is UnrealIRCd. That's where the fix needs to be made.

Erm... I don't mean to be rude, but have you actually read what other people posted other than Khaled?

Regards,

I did, but then I ignored the ones who posted just to flame an IRCd.

Why? Nobody ignored the unreal ircd team's posting when it simply flamed an IRC client?

The "flame" posts actually give reasonable criticism to certain features of the ircd which seem to be causing the problems you have with this bug.

Regards,

I'm sure some of this has been said already, but I haven't read the whole thread.

Can you name a scenario where a part command will actually fail? I can't think of one unless there's some kind of badly written IRCD playing a part.

Since a part command will always succeed, surely it's beneficial to have the window close instantly, rather than wait until the part receipt is received? I can't see any possible reason why somebody would rather have the window close a second after they hit the button (in the case of high lag, could be even longer), rather than instantly.

That is precisely what the rest of the thread has illustrated. UnrealIRCd has a /shun ability which apparently means the server ignores all commands from a particular client, effectively trapping them on the network. So, if you've been shunned, /part is ignored. So the way I see it is, certain people want to prevent shunned users from closing their windows. Need I say more?

Regards,

Ah.

Do UnrealIRCd's announce the 'SHUN' ability in an 005 (or something)?

If so, more dodgey-ircd-dependent code could be made..

While being shunned disables most commands from a client, /quit and /exit do still work. I thought /part worked as well, but I've been unable to find confirmation of this, one way or the other.

Well then whoever wrote the unrealircd documentation doesn't know what the meaning of the word "ANY" is.

"Prevents a user from executing ANY commands and prevents them from speaking."

To me, /part would be included in this.

Edit: There seems to be a setting ("set::options::allow-part-if-shunned;") that allows users who are shunned to still /part. I would imagine the default setting is that a user can't.

Regards,

Answer to my own question: According to the source, No.