On Bug #76369 I wrote:

> TpBaseConnectionManager:protocols (because it contains their properties)
> TpBaseConnection:requestable-channel-classes
> TpBaseConnection:dbus-status
> TpExportableChannel:channel-properties

These are done in a branch. http://cgit.freedesktop.org/~smcv/telepathy-glib/log?h=rm-dbus-glib-properties1

Still to do:

Misc
----

> TpBasePasswordChannel:sasl-error-details (but it's internal anyway)

Not used in the "big 5" CMs.

> TpBaseProtocol:immutable-properties

Gabble uses that, and overriding it is documented to be how you extend the Protocol. I think we should make it into a GVariant.

The Call stuff
--------------

> TpBaseCallChannel:contents, TpBaseCallChannel:call-state-reason,
> TpBaseCallChannel:call-state-details, TpBaseCallChannel:call-members,
> TpBaseCallChannel:member-identifiers
> TpBaseCallContent:streams
> TpBaseCallStream:remote-members (but it would be fine with a different GType)
> TpBaseCallStream:remote-member-identifiers (but it would be fine with a
> different GType)
> TpBaseMediaCallContent:remote-media-descriptions,
> TpBaseMediaCallContent:local-media-descriptions,
> TpBaseMediaCallContent:media-description-offer,
> TpBaseMediaCallStream:local-credentials,
> TpBaseMediaCallStream:local-candidates, TpBaseMediaCallStream:stun-servers,
> TpBaseMediaCallStream:relay-info, TpBaseMediaCallStream:endpoints (but it
> would be OK with a different GType)
> TpCallContentMediaDescription:codecs, TpCallContentMediaDescription:ssrcs,
> TpCallContentMediaDescription:header-extensions,
> TpCallContentMediaDescription:feedback-messages
> TpCallStreamEndpoint:remote-credentials,
> TpCallStreamEndpoint:remote-candidates,
> TpCallStreamEndpoint:selected-candidate-pairs,
> TpCallStreamEndpoint:endpoint-state,
> TpCallStreamEndpoint::candidate-selected,
> TpCallStreamEndpoint::candidate-accepted,
> TpCallStreamEndpoint::candidate-rejected

None of those are used in the "big 5" CMs.

> TpBaseMediaCallContent::local-media-description-updated

Rakia and Gabble do use that.

(In reply to comment #1)
> > TpBasePasswordChannel:sasl-error-details (but it's internal anyway)
> 
> Not used in the "big 5" CMs.

Still to do, probably best to do on this bug.

> > TpBaseProtocol:immutable-properties
> 
> Gabble uses that, and overriding it is documented to be how you extend the
> Protocol. I think we should make it into a GVariant.

Still to do, but I'll consider it to be part of Bug #77197.

> The Call stuff

Still to do as part of Bug #77196.

http://cgit.freedesktop.org/~smcv/telepathy-glib/log?h=rm-dbus-glib-properties2 implements everything that has not been moved to another bug.

 - "TpBaseConnectionManager:protocols: remove": Hmm, there is a _dup_interfaces() and _get_interfaces() and both actually return a new GPtrArray... confusing... I don't think we should rename the vfunc to dup_interfaces() but at least I would add a _impl suffix, or _dup_interfaces_property(), or something else?

 - In the same commit, unrelated, but I spotted /* copy the klass->interfaces property for backwards compatibility */ do we still use that klass->interfaces? should be remove it? or we don't care?

+1 for the rest.

(In reply to comment #4)
>  - "TpBaseConnectionManager:protocols: remove": Hmm, there is a
> _dup_interfaces() and _get_interfaces() and both actually return a new
> GPtrArray... confusing... I don't think we should rename the vfunc to
> dup_interfaces() but at least I would add a _impl suffix, or
> _dup_interfaces_property(), or something else?

I don't think this is critical-path.

TpBaseConnectionManagerGetInterfacesFunc, the implementation of the TpBaseConnectionManagerClass.get_interfaces vfunc, returns (transfer container), because in 99% of CMs the interfaces are static strings anyway.

tp_base_connection_manager_get_interfaces() is not API. It is the default implementation of TpBaseConnectionManagerClass.get_interfaces(). I could rename it to ..._real_get_interfaces() if you want.

tp_base_connection_manager_dup_interfaces() is not API either. It returns a deep-copy of the same thing as a GStrv, because that's what we want for the property.

TpBaseProtocol has the same design.

I'm tempted to make our base classes into GDBusObjectSkeleton subclasses, which would mean we could replace these functions altogether (the replacement would be a vfunc returning a GList<GDBusInterfaceSkeleton>), but there are some logistical problems involving TpDBusPropertiesMixin, so I'd rather do these lower-hanging fruit first.

(In reply to comment #4)
>  - In the same commit, unrelated, but I spotted /* copy the
> klass->interfaces property for backwards compatibility */ do we still use
> that klass->interfaces? should be remove it? or we don't care?

Yes we should remove it. It's _TP_SEAL'ed, so CMs don't use it anyway.

TpBaseProtocol has the same design.

(In reply to comment #4)
> +1 for the rest.

Merged the rest for 0.99.11.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/124.