Summary: | Call1: Should give contact IDs with handlers | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Xavier Claessens <xclaesse> |
Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | olivier.crete |
Version: | unspecified | Keywords: | patch |
Hardware: | Other | ||
OS: | All | ||
URL: | http://cgit.collabora.com/git/user/xclaesse/telepathy-spec.git/log/?h=call1-ids | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Xavier Claessens
2011-11-04 06:18:34 UTC
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.