[Bug 38142] proxy factories

[bugzilla-daemon at freedesktop.org]

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

--- Comment #1 from Xavier Claessens <xclaesse at gmail.com> 2011-06-10 02:41:01 PDT ---
What I don't like with current code:

1) TpBasicProxyFactory is supposed to _implement_
TpClientChannelFactoryInterface, but it actually have no code at all, since the
interface already implement the methods. I think the interface should print
warning and return NULL if one of its method is called but not actually
implemented by the object.

2) TpAutomaticProxyFactory and TpBasicProxyFactory are separate objects
implementing the same interfaces. That means that if we want to add a
TpClientAccountFactoryInterface it will have to be reimplemented in both
objects, even though Automatic would have nothing to add compared to Basic in
that case I think. IMO TpAutomaticProxyFactory should be SUBCLASS of
TpBasicProxyFactory, in a way that if the Automatic has nothing to add to the
Basic behaviour, it simply fallback to parent implementation.

3) struct _TpBasicProxyFactory {GObject parent;}; --> no place to add a
"gpointer priv" without breaking ABI. But we need to add a priv struct for
holding the proxy cache for uniqueness...

4) it mentions "proxy" in the name reffering to TpProxy, but if we want to use
it for TpContact that's not true... no a real issue though :)

What I suggest:

1) create TpSimpleClientFactory, subclass of GObject, that will have virtual
methods like _create_channel(); _create_connection();
_dup_features_for_channel(); with default implementation to return
tp_channel_new(); tp_connection_new(). It will also have a TpProxy
*tp_simple_client_factory_proxy_lookup(self, object_path); that gives the
cached proxy if already exists. Technically that would be a 'protected' method
in C++ terms used by subclasses that reimplement some methods to see if a proxy
already exists, but doesn't hurt to be public.

2) create TpAutomaticClientFactory, subclass of TpSimpleClientFactory, that
will reimplement _create_channel() returning tp_text_channel_new() and fallback
to chainup to parent implementation (just like we chainup in GObject
constructed, dispose, etc). It will also reimplement
_dup_features_for_channel(); by first chaining up to parent to get the CORE
features, then add more into the array before retuning.

3) TpUserClientFactory, subclass of TpAutomaticClientFactory, that will
reimplement _dup_features_for_connection() by first chaining up to parent impl
to get the features from the automatic factory, then add features asked by user
using something like tp_user_client_factory_add_features_for_connections().

4) EmpathyClientFactory, subclass of TpUserClientFactory, that will do
reimplement methods for creating EmpathyTpChat and EmpathyContact subclasses,
but relies on parent implementation for all the rest.



This proposal does not need interfaces, all is virtual methods. It has the
disadvantage of replacing the limited factory code we already have (they would
be deprecated). I personally prefer my design but I'm surely open to comments
:)

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