Bug 184820 - t-a-k magnificently fucks up if some other process changes the presence of a connection
Summary: t-a-k magnificently fucks up if some other process changes the presence of a...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: telepathy
Classification: Unmaintained
Component: general (show other bugs)
Version: git-latest
Platform: Compiled Sources All
: HI normal
Target Milestone: 0.4.0
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-18 17:53 UTC by George Goldberg
Modified: 2012-07-06 12:47 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George Goldberg 2009-02-18 17:53:59 UTC
If t-a-k  sets up a connection, but then some other process alters its presence, then t-a-k doesn't handle what to do at all. The only case where it does^Wshould work is when taking the connection offline.

What should happen: The CurrentPresence property for that account should be updated to reflect the changed presence, and nothing else. 

Quoting IRC discussion on the subject earlier today:

<grundleborg_q> smcv: what should AM do in the following scenario: Account is brought online, then someone disconnects said account directly without going through the AM?
<grundleborg_q> smcv: should it reconnect automatically? what if connect automatically is set?
<smcv> grundleborg_q: unspecified. I'd make it do nothing until the next time RequestedPresence is changed
<grundleborg_q> smcv: ok cool - thats easy :)
<grundleborg_q> I'll just update CurrentPresence then
<smcv> grundleborg_q: out of a vague feeling of "well, the user knows best"
Comment 1 George Goldberg 2009-09-22 17:55:20 UTC
T-A-K has been superseded by Mission Control 5.3