[Bug 47296] Call: Can not be used with Approvers

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47296

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-03-23 06:25:07 PDT ---
(In reply to comment #0)
> 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.

Why does the Call spec say this? The only rationale I can find is "to reduce
the probability that the user will pick up the call and have it immediately
fail". In what situations would this happen? Being behind a particularly nasty
firewall?

I feel as though the user should be notified that someone tried and failed to
call them (or at least Telepathy shouldn't make it unnecessarily hard to do
so), but it should probably look more like an instantly-missed call than an
"answer?" prompt, yes.

The Call spec as written defeats part of the purpose of Approvers, which was to
avoid taking up memory/CPU time/bandwidth for an operation that the user hadn't
agreed to (being in a call). Perhaps that's a necessary sacrifice to make VoIP
reliable, though - you want to start the ICE process as quickly as possible,
right?

It's possible for a Call Handler to be an Observer, Claim() the CDO
non-interactively, and deal with notification and "user-approval" internally. I
think the N900/N9 might have done this? This would defeat parts of the purpose
of Approvers while preserving others.

The other major purposes that I can remember for Approvers are:

* Be a second phase of dispatching, strictly after Observers. This ensures
  that bits of UI from Approvers don't pop up in the user's face if an
  Observer has already taken action as a non-interactive approver: for
  instance, a call-screening implementation could be an Observer and
  pre-emptively reject calls from undesirables, without the user ever
  seeing a notification bubble or hearing a ringtone. This part wouldn't
  be defeated by having Handlers do approval.

* Avoid having a UI pop up and interrupt the user. Calls have to do this
  a bit to meet normal expectations of how intrusive/urgent a call should
  be treated as, but a Call Handler that does its own notification
  and user-approval can minimize this.

* Avoid divulging that the user is even online at all
  if they don't want to talk to the remote party. If you want to start
  ICE as early as possible, then this isn't really possible, though.

* Choose the Handler explicitly (for "always give the user every
  possible choice" UIs) or implicitly (the user can be nagged by more
  than one Approver, but can only say "yes" to one of them, and that
  Approver's favourite Handler gets priority).

One reason for multiple Approvers is "the full-screen media player use case".
While running, a full-screen media player which you can run on your desktop or
a dedicated machine (I think the one we discussed was Elisa?) wants to be an
Approver so *it* can notify you of incoming calls; Empathy/Shell in the
background will still notify you, but not visibly, because Elisa is in the way.

Another reason for multiple Approvers is that you can have your Bluetooth
headset and your touchscreen be independent Approvers, which say "yes" when you
press the "answer" button on either the headset or the touchscreen. (I think
the N900 might even have implemented this?)

> 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

How can this work if you have both Empathy and telepathy-kde installed? Would
they both have their Handler not be activatable, and run it as a side-effect of
running a main process or entering the desktop session?

In the Elisa use-case, how does Elisa take over from Empathy or telepathy-kde
and impose itself as the preferred Handler?

(Not entirely a rhetorical question: one possible answer is to do clever things
with D-Bus name-ownership semantics - but that requires a special case for Call
channels in the spec, rather than using generic dispatching machinery that
doesn't know about channel types, and I think that'd be a backward step.)

The same questions apply to Text channels.

> - Drop the DispatchOperation (do we really have any case where you dispatch
> more than one channel at the same time).

(We do, in MUC Tubes channels, but nobody copes with it.)

The CDO needs to exist in MC in some form - it contains most of the logic for
actually dispatching channels (at least since I refactored it - before I did
that, McdDispatcher was giant and impossible to understand). Channel requests
also have a secret CDO which isn't visible on D-Bus, but exists internally.

It'd be possible to have the dispatcher D-Bus API be entirely in terms of
calling a method on the ChannelDispatcher and passing the Channel (or
Channels?) you're talking about as an argument,  but I don't think that'd help
clarity.

The CDO is also somewhere we can put things that are part of MC's state, but
not part of the Channel in the CM. There's not much of that yet, but the list
of possible handlers is there, and I think it's somewhat important to have it
as an extension point for the future. (In outgoing calls, the ChannelRequest
takes on this role, which is partly why the CDO isn't made visible on D-Bus.)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.