[Telepathy] Dispatcher use cases (was Re: Problem to reuse existing channel when creating a call/chat)

[Xavier Claessens]

I recently dropped usage of NMC's dispatcher in empathy. I think it's
too much limited. Here are some use cases to take in account for
dispatcher spec:

1) The logger could be in a dedicated process (trackerd?). So we need it
to get Text channels before the chat UI.

2) For INCOMING text channels both the status icon and the contact list
(possibly different processes) need the channel to make the icon blink.
The chat UI shouldn't be started unless the user click on either the
status icon or the contact list. When the user click on the contact list
the status icon should be warned so it stop blinking.

3) Chat UI shouldn't Close text channels, some programs could want to do
some post-process things. I can't think about a concrete job here but
that could happen I guess.

4) Each Tube and FT should be dispatched separately. Case 1, 2 and 3
apply to them too. I suppose that case will be fixed by chaning the spec
so we have one channel per tube/ft?

5) The TicTacTube game have a Tube channel, it could want to request a
Text channel for the same users and embed a UI itself. For that channel
to chat UI shouldn't be started but the logger should handle it?

6) The chat UI crash (or the user kill it, etc), text channels should
either get closed OR channels should be redispatched so the chat UI
restarts and display not acknowledged messages.

7) See the email I'm replying to.

8) When chatting with a contact I could want to embed an Audio/Video
conf. The media channel shouldn't be dispatched, the chat UI handle it
itself.

Other problems with current NMC chandler/filter:
 - When MC crash or user set presence to offline then back to online,
all filters are lost and not used anymore. So chat UI is popup directly
one INCOMING text channels without first blink the status icon.
 - When empathy quit without disconnecting MC then restart old filters
are not removed and empathy register new ones. So when a new channel
INCOMING channel arrives the user have to click 2 times on the status
icon.
 - Use case 2 and 7 are impossible to implement AFAIK.
 - In use case 6 all new messages are lost. Don't think it's possible to
fix that nicely with current dispatcher.

Will poste another email if I think about something else.

Xavier Claessens.


Le jeudi 17 avril 2008 à 18:48 +0200, Xavier Claessens a écrit :
> Hi,
> 
> We discussed a problem on IRC and I'll summarise it with a simple
> real-live use-case:
> 
> Alice has a megaphone applet[1] on her gnome-panel with Bob's contact.
> When she clicks on that applet a audio/video call starts with Bob.
> 
> Alice also have empathy's contact list, when she clicks on the
> microphone icon near Bobs's avatar it starts a call with Bob.
> 
> Alice calls Bob using the empathy's contact list, then do something else
> (she don't need to have focus on the call window to speak with her
> microphone). At some point she wants to get the focus back to the call
> window and clicks on the megaphone applet because she don't know where
> the window is (could be on another desktop, lost somewhere).
> 
> Actual result: A 2nd call is initiated
> Expected result: The existing call window get focus because the system
> knows that's stupid to call the same person twice.
> 
> The problem: The megaphone applet and empathy contact list are 2
> different processes so they can't know that there is already an existing
> channel for that call. They could list all existing channels and check
> one-by-one if that's the channel for the call it wants but then it has
> no way to tell the call-channel-handler that that call should get the
> focus.
> 
> With named channels (handle_type != 0) and NMC4.x that can be worked
> around by requesting again the channel so it get dispatched again and
> the channel handler can see if there is already a window showing the
> (handle_type, handle) tuple and give focus to it if it exists, create a
> new window otherwise. However we discussed that redispatching channels
> is wrong and that solution doesn't work for unnamed channels, so we need
> a better way.
> 
> Xavier Claessens.
> 
> 
>