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

[bugzilla-daemon at freedesktop.org]

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

          Priority: medium
            Bug ID: 76111
          Assignee: telepathy-bugs at lists.freedesktop.org
           Summary: [next] Make TpProxy subclasses API more coherent
        QA Contact: telepathy-bugs at lists.freedesktop.org
          Severity: enhancement
    Classification: Unclassified
                OS: All
          Reporter: guillaume.desmottes at collabora.co.uk
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: tp-glib
           Product: Telepathy

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

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