Bug 18058

Summary:	no good way to clean up lost-in-space connections you'd like to recreate
Product:	Telepathy	Reporter:	Will Thompson <will>
Component:	tp-spec	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED MOVED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	minor
Priority:	low
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Will Thompson 2008-10-14 04:53:28 UTC

When you call RequestConnection for a connection that already exists, telepathy-glib-based CMs return NotAvailable. There's no way to get rid of the existing connection so that you can make a new one. This leads to the following situation:

1. A Telepathy client makes a Connection, never calls Connect() on it, and quits.
2. Empathy tries to connect to that account, but MC can't make a connection.
3. No IM for you!

This situation arises in practice because something (MC?) makes connections and forgets about them.

Currently, you can work around this by setting Empathy to offline and then online again, due to MC4's "kill everything on startup" behaviour. But in general, you have to either log out and in again, or know how to drive Telepathy-Inspector.

Discussion on #telepathy lead to a proposed solution:

1. Add a specific error which RequestConnection returns if the connection already exists.
2. Add a method to ConnectionManager which kills off any clashing connections and returns you a new one.
3. UIs could then react to 1. by offering a button to call 2.

Comment 1 Will Thompson 2008-10-14 09:50:42 UTC

Daf, Sjoerd, Simon and I came to something resembling agreement on this.

Suppose I request a connection with { username: "badger@mushroom.cym", password: "secret", resource: "snake" }, then forget about it, and request it again. Currently, the CM will return an error.  Instead, it could return *another* independent connection with those properties (at a different bus name/object path).  If the first connection is never Connect()ed, then everything works as expected.

If two connections with the same properties are used in parallel, one might be disconnected when the other one Connect()s (on protocols like MSN), or have its username/resource mangled (with some XMPP servers or IRC), etc. But this is no different to connecting to the same IM account on multiple devices.

Implementation: always include the address of the TpBaseConnection * (or equivalent) in Connections' bus names and object paths.  A refinement would be only to uniquify in the event of a conflict.

(We need to do something similar to this anyway in Idle to fix https://bugs.freedesktop.org/show_bug.cgi?id=17430 .)

Comment 2 Will Thompson 2009-07-28 02:20:03 UTC

Lowering priority and changing severity: the account manager solves this problem for you, by managing your connections. This is only an issue if you're calling RequestConnection() directly.

Comment 3 GitLab Migration User 2019-12-03 20:17:38 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/15.

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.