Skip to content

[next] Make TpProxy subclasses API more coherent

Submitted by Guillaume Desmottes @gdesmott

Assigned to Telepathy bugs list

Link to original bug (#76111)

Description

I sorted the different Proxy subclasses into the following categories:

Can be created by the user using only using TpClientFactory

  • TpAccount
  • TpChannel
  • TpConnection

All fine.

Created internally by tp-glib using TpClientFactory

  • TpChannelDispatchOperation
  • TpChannelRequest

The point of using the factory is to use the caching mechanism ensuring that we won't end up with 2 different proxies for the same object.

User is not supposed to create those manually so I don't think there is anything to change here.

Created internally by tp-glib without using TpClientFactory

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

Should we change those to use the factory internally and so benefit from its cache?

Can be created by user using a specific API

  • TpProtocol: but bug#75881 is going to move it to the factory
  • TpTLSCertificate: I guess it could use the factory instead

Should these 2 use the factory? I guess we could?

  • TpChannelDispatcher

  • TpLogger

  • TpConnectionManager: as I said on bug#75881 the connection manager is not considered as a "top level object". Maybe it should be?

  • TpAccountManager

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

Depends on