When changed various properties/signals in Channel iface to ensure we always give contact IDs with handlers. This makes stuff easier in client-side because they can create TpContact objects without extra async calls. Here are the properties/signals affected: Call1::CallMembers Call1::CallMembersChanged Stream::RemoteMembers Stream::RemoteMembersChanged
I don't think its necessary to add it to the stream as it's always a subset of the contacts that are in the channel.
Depends if we can guarantee that RemoteMembersChanged is always emitted AFTER CallMembersChanged. Otherwise we would have to wait for CallMembersChanged to give the contact id because handling the RemoveMembersChanged. I guess both will usually happen at the same time, if we want to depend on an exact ordering that needs to be defined in spec as well.
(In reply to comment #2) > give the contact id because handling the RemoveMembersChanged. ... before handling ...
I guess we can add that "Any member mention in Stream::RemoteMembers must be a member of the Call channel" or something like that.
Here is a patch. I think it's easier and safer to just let include all identifiers to Streams as well, instead of depending on precise ordering of signals. This will make easier to implement the client-side API.
I don't care much either way.. It's a bit more dbus traffic, but I guess we're well past that in Telepathy.
ok, merged like that.
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.