[Bug 31001] channel client factory: add API for TpChannel preparation

[bugzilla-daemon at freedesktop.org]

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

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-20 05:42:25 PDT ---
(In reply to comment #0)
> -  Add GQuark *features tp_client_channel_factory_get_features
> (TpClientChannelFactoryInterface *self, TpChannel *self) implemented using a
> virtual function returning CORE as default implementation.
> Or maybe we should return a more flexible structur to make it easier to merge
> it with TpBaseClient's features?

I'm not sure what structure we'd return; perhaps a GArray?

> - Modify TpBaseClient to prepare the union of its features and the ones
> returned by _get_features(). I guess that's fine if we ask to prepare twice the
> same feature.

It should be OK, yes; preparing one "batch" which may contain duplicates is
probably a little more efficient than two overlapping "batches".

> - Implement _get_features () inTpAutomaticProxyFactory  by returning CORE +
> TP_CHANNEL_FEATURE_GROUP if the channel implements Group.

IMO there's no need for this: just include TP_CHANNEL_FEATURE_GROUP
unconditionally, and have the guarantee be "well, we tried".

> - I'm not sure if we want to add API on TpClientChannelFactoryInterface to add
> features? It seems weird to add features on a factory which already created
> channel. And clients can still add feature on TpBaseClient or create their own
> factory if needed.

Yes, I think leaving this out is the conservative route. You could always have
an EmpathyProxyFactory subclass of TpAutomaticProxyFactory which just overrides
this method, if you wanted.

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