Connection should have more D-Bus properties, accessible via GetAll: * Status : u, Connection_Status * Protocol : s, Protocol * ConnectionManager : s, Connection_Manager_Name * Interfaces : as, DBus_Interface_Name[] * etc. (but not StatusReason, because by the time it's non-obvious, the connection has already gone away)
(In reply to comment #0) > * Status : u, Connection_Status > * Protocol : s, Protocol > * Interfaces : as, DBus_Interface_Name[] I'd already done these on 'next' with my first push branch. > * ConnectionManager : s, Connection_Manager_Name What's the point of this one? I can't think of a time when given the connection I needed to know the CM name. The account triple can be useful but we have a function in tp-glib to split that up already?
(In reply to comment #1) > What's the point of this one? I can't think of a time when given the connection > I needed to know the CM name. The account triple can be useful but we have a > function in tp-glib to split that up already? I never got a reply to this. I still don't think there's a big rush for this and it can be added easily later without breaking API if it really needs to be. Closing.
(In reply to comment #1) > (In reply to comment #0) > > * Status : u, Connection_Status > > * Protocol : s, Protocol > > * Interfaces : as, DBus_Interface_Name[] > > I'd already done these on 'next' with my first push branch. > > > * ConnectionManager : s, Connection_Manager_Name > > What's the point of this one? I can't think of a time when given the connection > I needed to know the CM name. The account triple can be useful but we have a > function in tp-glib to split that up already? It is used to build avatar cache path, and logger stuff. But this can be found by parsing the object-path. That's how tp_account_get_connection_manager() and tp_connection_get_connection_manager_name() works. So a property would be useless redundant information IMO. (side not: tp_account_get_connection_manager() should be renamed to tp_account_get_connection_manager_name() since it returns the name and not a TpConnectionManager object).
actually we have a "protocol" property but not "connection-manager", this is somewhat inconsistent. I would suggest droping the "protocol" since it can be found in object-path.
Created attachment 63263 [details] [review] Connection: drop Protocol property The protocol can found by parsing the connection's object-path, just like the Connection Manager name.
Merged.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.