[Bug 77189] [next] make TpBaseConnection GVariant-based

[bugzilla-daemon at freedesktop.org]

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

--- Comment #12 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
> TpExportableChannel, TpChannelIface: remove

This is Bug #77287, which I closed as a duplicate of this one.

Definitely remove TpChannelIface, it's crap.

I'm still a little unsure about removing TpExportableChannel - it makes
telepathy-glib more tightly-coupled. OTOH, ever since TpBaseChannel was added,
we've never had any reason to implement a channel that is not a TpBaseChannel.
So, yeah, let's go for it. We can always add parallel APIs (or relax
assertions/casts) in the unlikely event that this turns out to have been a
mistake.

> + * This base class makes it easier to write channels
>   * implementations by implementing some of its properties, and defining other

"channel implementations"

> - * If the #TpExportableChannel:object-path property is not set at construct
> + * If the #TpBaseChannel:object-path property is not set at construct

When we turn it into a GDBusObjectSkeleton, I wonder whether we should switch
to using GDBusObjectSkeleton:g-object-path. It's read/write/construct but not
construct-only, FWIW.

> +   * If the channel implementation uses
> +   * <link linkend="telepathy-glib-dbus-properties-mixin">TpDBusPropertiesMixin</link>,
> +   * this property can implemented using
> +   * tp_dbus_properties_mixin_make_properties_hash() as follows:

Hmm, this is interesting. That won't necessarily work any more once you have
switched the channel to be a GDBusObjectSkeleton, because not all the
properties will necessarily be TpDBusPropertiesMixin-mediated...

I think we'll need a vfunc that fills a GVariantDict, and a note that
overriding the vfunc is a better way to do things than overriding the property.

We can cross that bridge when we come to it, though.

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