[Bug 29973] TpClientChannelFactory interface and TpDefaultChannelFactory

[bugzilla-daemon at freedesktop.org]

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

--- Comment #20 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-11 02:47:02 PDT ---
(In reply to comment #19)
> > Hmm. Does this mean that if you want to have control over both TpChannel and,
> > say, TpChannelDispatchOperation, you're going to have to call both
> > set_channel_factory and set_cdo_factory?
> 
> Humm, we could have a set_proxy_factory that will be used for all proxy
> creation in TpBaseClient. But that implies that if we add more type of proxy
> later, we'll have to check that the factory implement the new interface before
> using it (which is fine). set_factory will take a GObject * (or gpointer?) as
> argument.

If you can think of a reasonably nice way to do this right now, go for it!

If you can't right now, we could always deprecate set_channel_factory later, in
favour of a future set_proxy_factory.

> > Should we have a tp_automatic_proxy_factory_dup()? I expect it'll be quite
> > commonly-used.
> 
> Should I replace _new() by _dup() and so define this object as a singleton? I
> guess that's ok

Only if you don't think it'll ever be useful to subclass
TpAutomaticProxyFactory. I think subclassability plus a _dup() convenience
function is probably more useful here than the singleton-in-constructed()
pattern, tbh?

One issue I can think of which isn't relevant for Channel, but is for some of
the other proxies, is: should the proxy factory have a TpDBusDaemon property?
I'd actually be inclined to say the answer is "no, all the methods should
either take a TpDBusDaemon, or a 'smaller' object like TpAccountManager, as an
argument".

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.