[Bug 31583] Expose TpProxyFeature in the API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-11-18 01:13:20 PST ---
(In reply to comment #4)
> * a check for whether they've already completed (feature-specific: the feature
> might be able to grow extra functionality after CONNECTED)
> 
> * a check for whether we want them (not needed when called as
> start_preparing(), but needed when CORE introspection has progressed)
> 
> * a check for whether the object's CORE/CONNECTED functionality is ready
> (feature-specific: they might be able to achieve something without CONNECTED)
> 
> * a check for whether the same preparation is already in-flight
> 
> * a check for whether we have the desired interface
> 
> Also, the functions are generally called from two places: once from the
> introspection pipeline, and once from the feature pseudo-vtable by TpProxy.

Can't we solve most of this by adding some guarantee about
when start_preparing() is called: "start_preparing() is called only once when
we actually want to
prepare the feature and we are not already preparing it".

We could add API saying if we need CONNECTED or CORE prepared or not.

> Features that don't need CONNECTED, but grow more functionality after CONNECTED
> (of which there aren't any yet, but SimplePresence would be one such) need to
> be able to delay CONNECTED state, which currently means they need to be able to
> call into the object-specific introspection pipeline.

I'm not sure to understand this. Why is SimplePresence special?

> What feature in Empathy needs this? Can we put that feature in telepathy-glib
> instead?

I'm trying to get ride of EmpathyTpChat by using TpTextChannel. For now my
TpTextChannel implementation doesn't offer all the features provided by
TpTextChannel, so as a transitionnal step I'm rebasing EmpathyTpChat on top of
TpTextChannel (relying as much on TpTextChannel as possible).

One of this feature is about channel "upgrades" (using Conference), and it
needs to check if the Connection supports Conference. To do so, the
TpConnection of the channel needs to have TP_CONNECTION_FEATURE_CAPABILITIES
prepared which we can't guarantee. So I need to have a CORE feature on
EmpathyTpChat that will do this preparation and init the needed bits in
EmpathyTpChat.

Anyway, not being able to define our own features kinda misses most of the
point of having user-defined TpChannel subclasses (which was one of the main
goal when we designed channel factories).

-- 
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.