[Bug 55104] Provide GVariant-based access to TpCallChannel:state-details

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #5)
> > Any thoughts on whether to squash the variant, or maybe even the state and
> > flags too, into the TpCallStateReason (with a rename to ...StateDetails or
> > something if it gains the state and flags)?
> 
> If we're fine with loosing the coupling with
> http://telepathy.freedesktop.org/spec/Channel_Type_Call.html#Property:
> CallStateReason yeah I think that's fine.

(Not done in the branch I reviewed.)

CallStateReason appears to be used for both CallStateChanged (where it's
emitted alongside the state, flags and a{sv} details), and ContentRemoved
(where there are no further details).

I started to write "I wonder whether we should have individual getters for all
the bits and pieces?" but that would be a really annoying API. I think state
and flags as individual getters make sense, but the various reason codes should
really be bundled together, so advanced UIs can do the usual Telepathy
"string-match D-Bus errors, fall back to switch() on error codes" dance.

I think normally we'd have a getter with multiple "out" values, but then we'd
have difficulty putting it in a signal.

I notice with annoyance that we have both Call_State_Reason.Message and
CallStateDetails["debug-message"], which appear to be 100% redundant - in 1.0
we should drop one of them, and if the one we keep is
Call_State_Reason.Message, put a note in CallStateDetails that says "note that
maps like this in Telepathy usually have a "debug-message" key, but in Call1
the same information goes in Call_State_Reason.Message".

I wonder whether it would make most sense to turn Call_State_Reason from a
(uuss) to a (uussa{sv}) (or perhaps (uusas{sv}) if we keep "debug-message" but
not Message), so we're able to have extensible details in CallMembersChanged
and ContentRemoved, not just in CallStateChanged?

I also think that if this thing is going to be C API, we should expose its ref
and unref functions.

> > I would like to at least add some ABI padding to the TpCallStateReason.
> 
> Done.

Looks good for merge, while we think about the issue above.

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