[Bug 38142] proxy factories

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Jun 10 12:17:44 CEST 2011


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

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-06-10 03:17:41 PDT ---
(In reply to comment #2)
> factory = tp_user_factory_dup_singleton();
> tp_user_factory_add_account_manager_features (factory,
> [TP_ACCOUNT_MANAGER_FEATURE_ACCOUNT]);

Why is it a singleton if it has state?

(In reply to comment #0)
> Maybe TpContact as well (not technically a proxy, but same concept, and could
> open the door for EmpathyContact being subclass of TpContact).

It'd be useful to have the factory manufacture contacts in order to request
features, even if we don't allow subclassing.

One reason we don't allow subclassing is that allowing independent construction
is incompatible with per-(connection,handle) uniqueness of contact objects, but
factories can help to take care of uniqueness. Another reason to not allow
independent construction is to make contacts guaranteed-invisible to user code
until they've been set up enough for their handle/identifier to be known and
persistent.

If instead of a virtual method to construct a Contact, we have a (class
property that is|class method that returns) a GType that extends
TP_TYPE_CONTACT, then we can have subclassing without independent construction
(and also guarantee that all the contacts on a particular connection are of the
same class, which would reduce confusion!).

> 2) Do we want it to be able to upgrade all its existing proxies with more
> features when the user provide them? tpqt4 only let user add features to be
> prepared on new proxies, but existing ones would need to be upgraded manually
> if user need it.

Unless we have a concrete use-case for add_features_async(), I'd vote for
tpqt4's behaviour (which keeps adding features as a synchronous operation).

(In reply to comment #2)
> Forgot that we'll also need to add methods like
> 
> tp_proxy_set_factory(TpProxy *proxy, TpSimpleClientFactory *factory);

I think I'd prefer a construct-time property - proxies that can change factory
mid-life seem likely to be confusing. (Unfortunately, TpChannelRequest already
has a mutable factory, as does TpAccountChannelRequest - although the latter
could inherit its default factory from the TpAccount, maybe?)

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