Call: Can not be used with Approvers
Submitted by Olivier Crête @ocrete
Assigned to Telepathy bugs list
Description
Created attachment 58410 proposed spec patch
The way the Call spec works clashes with the way approvers where designed. I believe that the Call bit is the best way of doing things.
The problem is that the Call spec says that the user should not be notified of an incoming call before the Call reaches the INITIALISED state, but it will only reach that state when network connectivity has been been established, which requires a Handler to be present. So the handler need to runs before the approver. Which isn't how the Approver/handler interaction currently works.
In the short term, I'm proposing using BypassApproval for all Call channels so they go straight to the Handler.. And instead implement other Approvers as Observers that call Accept or Hangup on the channel... If an Observer (not the Handler) calls Hangup, then it would be the responsability of the Handler to call Close (so we can do CLEARING states correctly).
For the NEXT branch, I suggest we re-work the approver/handler process around the same principles for Call/FT/Tubes:
- Have a single Handler per type and call it right after observers
- add an optional Approvable interface that woudl contain: Accept(), Reject() and a property that would be "ReadyToAnnounce"
- have the approvers be called only if the Approvable interface exists and ReadyToAnnounce has turned to True
- Drop the DispatchOperation (do we really have any case where you dispatch more than one channel at the same time).
Patch 58410, "proposed spec patch":
0001-Explain-that-Approvers-can-NOT-be-used-with-a-Call-c.patch
Version: git master