| Summary: | Make sure it's easy to figure out the state of the channel (especially why it's in a certain state) | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Sjoerd Simons <sjoerd> |
| Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | Call | ||
| i915 platform: | i915 features: | ||
I don't understand this.
In your example, the call ended because the other side rejected it, so:
CallState=Ended
CallStateReason.Reason=User_Requested
and perhaps on top of that:
CallStateReason.DBus_Error=ofdT.Error.NoAnswer (or similar)
and if you're paranoid then you can confirm that it was the remote user who did this with:
CallStateReason.Actor=<the contact who rejected>
Is that right?
There's a lot to check, but that's Telepathy, and it's not so complicated. Exactly what are you suggesting?
Sjoerd and I just decided this is pointless for now. It could come back with DRAFT3 though. We will see. |
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.
> * Invent a channelstate for the health of the channel > > To make it easier the understand the overall state of the channel we should > have ChannelState property with an actor. So you only have to look at this > property to decide for example that the call ended because the other side > rejected it, without needing to dig in the CallState property