Bug 24273 - Add a "proxy mode" preventing MC parting channels when the UI crashes.
Summary: Add a "proxy mode" preventing MC parting channels when the UI crashes.
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: idle (show other bugs)
Version: unspecified
Hardware: Other All
: high normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://cgit.collabora.com/git/user/wj...
Whiteboard:
Keywords: patch
: 26363 (view as bug list)
Depends on:
Blocks: 21959
  Show dependency treegraph
 
Reported: 2009-10-02 02:01 UTC by Will Thompson
Modified: 2012-11-14 19:13 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Will Thompson 2009-10-02 02:01:19 UTC
When the channel dispatcher notices that the handler for a channel has crashed, it's supposed to call Close() on the channel. This works well for 1-1 text channels (which respawn) and just about every other type of channel (which stay dead) but for chat rooms this is undesirable. If you're using Idle through a proxy (or arguably, at all) you don't want all your IRC channels to be parted because your UI crashed.

The best solution seems to be to make Close() not leave the IRC channel, but make it respawn, and rely on RemoveMembers([self], ...) to leave channels. We can't unilaterally make this change, because it breaks the semantics of Close() — UIs need to be altered to use RemoveMembers() ­— so a boolean on the account to opt-in seems like a good way. But, this can't ever be removed, for backwards-compatibility reasons...

(Reasonably high priority: this is preventing some Empathy/Tp developers dogfooding Idle.)
Comment 1 Will Thompson 2009-10-19 03:34:32 UTC
Other possible implementations:

• Guess that the server is a bouncer from the connection process;
• Add a requestable channel property to turn this behaviour on;
• Add a settable channel property to turn this behaviour on.

Filing a corresponding spec bug, since this is similar to wanting to close a chatroom window without leaving the channel.
Comment 2 Alex Stansfield 2009-12-29 09:34:33 UTC
I've experienced this issue using the IDLE plugin on my Nokia N900.

I connected through a proxy (ctrlproxy), however the N900 implementation currently only handles private messages and not proper IRC channels. When it connected to the proxy it proceeded to remove me from the channels I was in. 

I guess this is because as the N900 doesn't handle channels the channel dispatcher saw this as a crash and closed the channels.

I originally created a bug at maemo.org (https://bugs.maemo.org/show_bug.cgi?id=7454) with details.

Comment 3 Will Thompson 2009-12-29 09:39:06 UTC
I have the beginnings of an Idle branch which detects when it's connected to a proxy (currently it just looks for the word "proxy" in the identity the server reports, which works for irssi-proxy, which I use) and changes its behaviour accordingly. URL attached.
Comment 4 Alex Stansfield 2009-12-30 04:48:24 UTC
Thanks for pointing out the branch. I've asked (very nicely) on the maemo bug tracker if there is any chance of it getting included in a telepathy-idle build for maemo.

Currently IDLE on the n900 seems a bit pointless without channels or proxy support. It really needs one or the other so that you can still use IRC fully whilst getting your private messages to the phone.

Thanks again.
Comment 5 Jonny Lamb 2010-02-01 11:12:49 UTC
*** Bug 26363 has been marked as a duplicate of this bug. ***
Comment 6 Will Thompson 2012-11-14 17:47:04 UTC
Okay, here's a branch that makes Close() respawn chat rooms, just like how it respawns 1-1 chats with unread mesasges. Destroy() and RemoveMembers([self], …) both PART the channel.

I didn't bother making it opt-in.
Comment 7 Sjoerd Simons 2012-11-14 19:08:10 UTC
Looks good, go for it!. Thank you for making my live better! :)
Comment 8 Will Thompson 2012-11-14 19:13:27 UTC
Merged to master. It'll be in 0.1.13.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.