[Bug 38142] proxy factories

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Xavier Claessens <xclaesse at gmail.com> 2011-06-10 04:08:00 PDT ---
(In reply to comment #5)
> (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?

Right, no need to be singleton, even if in practice apps would generally have
only one instance.

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

right, so unlike tp_simple_client_factory_create_channel() that returns a
TpChannel in sync call, for contacts that would be
tp_simple_client_factory_create_contacts_async(). Since the TpConnection inside
the factory is unique, that would guarantee the uniqueness of contacts just
like now too.

This makes me think that constructor methods on the factory could assert that
given objects comes from that same factory. For example:

TpChannel *tp_simple_client_factory_create_channel (self, conn, object-path)
{
  g_return_val_if_fail (tp_proxy_get_factory (conn) == self, NULL);
  ...
}

With such requirement, TpContact objects created from a factory are guaranteed
to all come from the same TpConnection object and so be per-factory unique as
any other proxy.

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

fair enough.

> (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?)

Right, that should be construct-only property. Sadly tp_*_new does not take the
factory in args, so that means we need to create tp_*_new_with_factory()...
well, actually that's good :)

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