mIRC Home    About    Download    Register    News    Help

Page 2 of 2 < 1 2
Topic Options
#178534 - 11/06/07 01:22 PM Re: Assuming PART is always successful [Re: Mentality]
Bekar Offline
Fjord artisan

Registered: 11/12/02
Posts: 503
Loc: Melbourne, Australia
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?).

Top
#178535 - 11/06/07 01:26 PM Re: Assuming PART is always successful [Re: Stealth]
qwerty Offline
Hoopy frood

Registered: 07/01/03
Posts: 2523
Quote:
1) Responsive UI, or "If the user says Close, we Close, no ifs ands or buts.":
Then go tell Microsoft Word they aren't supposed to give users a last chance to save documents. Or go tell themselves they can't ask for confirmation to exit when there's connections open.
...
But there are *plenty* of examples of windows programs (and GUI apps in general) that do not just go *zap* when you hit the X. If X was supposed to mean DIEDIEDIE windows wouldn't even give an option to cancel the event, now would it?
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?
_________________________
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com

Top
#178536 - 11/06/07 01:28 PM Re: Assuming PART is always successful [Re: Bekar]
RoCk Offline
Hoopy frood

Registered: 16/12/02
Posts: 2007
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.

Top
#178538 - 11/06/07 02:39 PM Re: Assuming PART is always successful [Re: Stealth]
starbucks_mafia Offline
Hoopy frood

Registered: 09/12/02
Posts: 2962
Loc: Norwich, UK
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.

Top
#178559 - 11/06/07 05:58 PM Re: Assuming PART is always successful [Re: Khaled]
Stealth Offline
Vogon poet

Registered: 07/09/03
Posts: 149
Originally Posted By: Khaled
Thanks for the comments, this is just my personal preference... implementing it the other way is easier (and I did try it out many years ago) but I felt more comfortable with the current behaviour. Is there some reason why you would prefer it to behave differently? Is it important?


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)
_________________________
mIRC 6.21 - Win XP Pro (SP2) - 2.4 Ghz - 1 GB Mem
irc.x-tab.org

Top
#178560 - 11/06/07 06:10 PM Re: Assuming PART is always successful [Re: Stealth]
starbucks_mafia Offline
Hoopy frood

Registered: 09/12/02
Posts: 2962
Loc: Norwich, UK
Quote:
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.
_________________________
Spelling mistakes, grammatical errors, and stupid comments are intentional.

Top
#178561 - 11/06/07 06:11 PM Re: Assuming PART is always successful [Re: Stealth]
Mentality Offline
Planetary brain

Registered: 01/06/03
Posts: 5024
Loc: London, England
Erm... I don't mean to be rude, but have you actually read what other people posted other than Khaled?

Regards,
_________________________
Mentality/Chris

Top
#178564 - 11/06/07 08:36 PM Re: Assuming PART is always successful [Re: Mentality]
Stealth Offline
Vogon poet

Registered: 07/09/03
Posts: 149
I did, but then I ignored the ones who posted just to flame an IRCd.
_________________________
mIRC 6.21 - Win XP Pro (SP2) - 2.4 Ghz - 1 GB Mem
irc.x-tab.org

Top
#178565 - 11/06/07 08:51 PM Re: Assuming PART is always successful [Re: Stealth]
Mentality Offline
Planetary brain

Registered: 01/06/03
Posts: 5024
Loc: London, England
Why? Nobody ignored the unreal ircd team's posting when it simply flamed an IRC client? smirk

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,
_________________________
Mentality/Chris

Top
#178579 - 12/06/07 12:09 AM Re: Assuming PART is always successful [Re: Stealth]
hixxy Offline
Hoopy frood

Registered: 06/09/05
Posts: 2876
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.

Top
#178581 - 12/06/07 12:36 AM Re: Assuming PART is always successful [Re: hixxy]
Mentality Offline
Planetary brain

Registered: 01/06/03
Posts: 5024
Loc: London, England
Originally Posted By: hixxy
I can't think of one unless there's some kind of badly written IRCD playing a part.


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,
_________________________
Mentality/Chris

Top
#178584 - 12/06/07 01:10 AM Re: Assuming PART is always successful [Re: Mentality]
hixxy Offline
Hoopy frood

Registered: 06/09/05
Posts: 2876
Originally Posted By: Mentality
UnrealIRCd


Ah.

Top
#178588 - 12/06/07 03:09 AM Re: Assuming PART is always successful [Re: Mentality]
Bekar Offline
Fjord artisan

Registered: 11/12/02
Posts: 503
Loc: Melbourne, Australia
Do UnrealIRCd's announce the 'SHUN' ability in an 005 (or something)?

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

Top
#178589 - 12/06/07 03:10 AM Re: Assuming PART is always successful [Re: Mentality]
RusselB Offline
Planetary brain

Registered: 03/08/04
Posts: 7252
Loc: Ontario, Canada
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.

Top
#178591 - 12/06/07 03:27 AM Re: Assuming PART is always successful [Re: RusselB]
Mentality Offline
Planetary brain

Registered: 01/06/03
Posts: 5024
Loc: London, England
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,


Edited by Mentality (12/06/07 03:34 AM)
_________________________
Mentality/Chris

Top
#178593 - 12/06/07 04:46 AM Re: Assuming PART is always successful [Re: Bekar]
Bekar Offline
Fjord artisan

Registered: 11/12/02
Posts: 503
Loc: Melbourne, Australia
Answer to my own question: According to the source, No.

Top
Page 2 of 2 < 1 2