Remaining design issues in ChannelDispatcher
req4: still need to spec InitialAudio, InitialVideo
Resolution: we do need to be able to request channels with no initial streams, so this is not a blocker. However, we want it very soon after the initial round of requestotron, as a way to express capabilities. https://bugs.freedesktop.org/show_bug.cgi?id=17246, https://bugs.freedesktop.org/show_bug.cgi?id=17584
CDO: should it persist until dispatching has completely finished?
- Resolution: Yes, because we might want to indicate that the handler didn't work
CDO.HandleWith, CDO.Claim: possible errors?
- Resolution: anything Handle can raise
req36, cancelling outgoing call: how do handlers cope with a race between remote channel closure and handling the channel? If they can, then req36d is OK. Should the CD follow up with a method call to say "never mind"?
- Resolution: existing problem, which we're not making any worse. Could be solved in future by having channels never close in response to remote events, only go into a "dead" state.
CDO: approvers need to be able to see when a channel gets closed before anyone claimed or approved it (a Missed signal maybe) - this is tied in with CDO lifetimes so all needs discussing together
Resolution: added ChannelLost signal
How do handlers indicate that their "main" name is officially the handler?
Resolution: they can always pass channels around among their various names, and the CD should only consider them to have crashed if the unique name goes away
Unresolved
A.ApproverChannelFilter: if we don't have approvers capable of understanding the whole batch, do we split it?
- Let's come back to this later. Perhaps Approvers need to handle all channels, always, anyway