[Bug 31583] Expose TpProxyFeature in the API

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jan 17 13:28:44 CET 2011


--- Comment #12 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-01-17 04:28:44 PST ---
(In reply to comment #11)
> Does that mean that if we have MY_CHANNEL_CORE_FEATURE, we shouldn't call its
> prepare function while TP_CHANNEL_CORE hasn't be prepared? We don't do that
> atm.

Yes, I think we should avoid preparing subclasses' core features until the
superclass's core feature is ready. I'm aware that this is a new guarantee that
we didn't previously have, but I think the semantics I proposed here are
probably what we want.

> >   /* If TRUE, allow retrying prep of this feature even if it failed once
> >    * already. ConnectionManager.CORE needs this. */
> >   boolean can_retry;
> How so? TP_CONNECTION_MANAGER_FEATURE_CORE is never explicitely prepared by
> the user (it doesn't have a prepare function).

Preparation is implicitly started by creating the object, but if the API user
calls tp_proxy_prepare_async twice at different times, it can return FALSE then
TRUE (if a buggy CM-under-test crashes the first time, then works correctly the
second time, for instance).

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

More information about the telepathy-bugs mailing list