[Bug 24107] support Statuses on TpConnection

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri May 14 14:32:39 CEST 2010


https://bugs.freedesktop.org/show_bug.cgi?id=24107

--- Comment #11 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-05-14 05:32:38 PDT ---
(In reply to comment #9)
> @@ +2518,3 @@
> + * The value may have changed arbitrarily during the time the Connection
> + * spends in status %TP_CONNECTION_STATUS_CONNECTING, again staying fixed for
> + * the entire time in %TP_CONNECTION_STATUS_CONNECTED.
> 
> You don't need this paragraph if you refuse to retrieve Statuses before going
> CONNECTED, as you currently do.
> 
> (But, don't do that... see elsewhere.)

"Elsewhere" is this comment. I was going to explain this in the review, but I
forgot :-)

Statuses is useful before CONNECTED (particularly inside MC), so the fact that
you check for ->ready is a problem.

Ideally it should behave like Interfaces. We don't actually download that using
properties at the moment - we still use GetInterfaces - but the principle is
the same.

Interesting strings to search for: introspecting_after_connected,
tp_connection_got_interfaces_cb.

The API I'd like is this:

* Whenever we start to fill the introspection queue (right now this means
tp_connection_got_interfaces_cb), enqueue a call to maybe_prepare_self_presence

* At the time that that callback is called, if we don't actually care, it'll
just do nothing

* After the real, underlying status goes to CONNECTED (you can tell by
introspecting_after_connected), re-fetch Statuses if it's wanted, before
signalling TP_CONNECTION_FEATURE_CONNECTED up to user code

You can probably achieve that fairly easily by storing a boolean
"final_statuses" alongside the hash table, and changing the check for "do we
already have the statuses?" to only do the early-return if (we already have the
statuses && (final_statuses || introspecting_after_connected)).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.



More information about the telepathy-bugs mailing list