[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