[Bug 76111] [next] Make TpProxy subclasses API more coherent

[bugzilla-daemon at freedesktop.org]

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

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #0)
> Created internally by tp-glib without using TpClientFactory
> -----------------------------------------------------------
> - TpCallContent
> - TpCallStream
> 
> Should we change those to use the factory internally and so benefit from its
> cache?

I'm not sure what benefit there would be? They're scoped to a TpCallChannel so
there should never be duplicates anyway? But, if you want, go ahead.

> - TpClient: actually it doesn't seem to be instantiated at all by tp-glib,
> only in its tests

Mission Control does create a subclass of TpClient directly. It could do that
by registering a factory subclass if desired.

> Should these 2 use the factory? I guess we could?
> - TpChannelDispatcher
> - TpLogger

If you like.

> But actually, shouldn't we consider the factory as the ultimate "top level"
> object and force user to create them using a factory as well? It would make
> the API more symetric and would allow us to remove some weird API like
> tp_account_manager_set_default() and tp_account_manager_can_set_default().

Yeah, perhaps. The concept of the default account manager is pretty strange; if
we have a default anything, it should be a default factory, associated with
tp_dbus_daemon_dup().

I think there does need to be a way to "go behind the factory's back" for at
least some of those objects, but it shouldn't be the primary API.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.