Contents
Juliet receives a message from Romeo that starts a new channel. Her desired UI resembles that of Empathy and of the Nokia internet tablets:
Current implementation, dis1impl1:
NewChannel (Text, CONTACT, handle("romeo@montague.verona.fict"), suppress_handler=FALSE) Mission Control runs filters, which include the blinking "new message" icon in the system tray When the tray icon is clicked, Mission Control continues processing filters and eventually dispatches to the channel handler
Problems addressed by proposed implementation:
We want a logger (which might be in a separate process) to be told to handle incoming text channels. This may require that:
If there is a logger, only it should be acknowledging messages (there will be problems if both the logger and the UI try to ack messages). This is conceptually rather odd if the logger is a filter.
The logger should be started immediately, without waiting for the new conversation to be accepted
As currently implemented, if MC crashes, filters are forgotten and the "new message" notification is skipped in future - the chat window pops up straight away, possibly stealing focus (bad!)
As currently implemented, if Empathy crashes and is restarted, its filter will end up registered twice, so the user has to click the incoming message icon twice
Alternative implementation, dis1impl2:
Problems with this alternative implementation:
Proposed implementation:
Dispatch process:
CM emits Requests.NewChannels([(channel_path, { '...ChannelType': '...Text', '...TargetHandleType': CONTACT, '...TargetHandle': 1234, '...TargetID': 'romeo@montague.example.com', '...Requested': FALSE, ... }, )]) In response, CD calls ObserveChannels on all matching Observers, including org.freedesktop.Telepathy.Client.EmpathyLogger CD creates a ChannelDispatchOperation CD calls AddDispatchOperation on all matching Approvers, including org.freedesktop.Telepathy.Client.EmpathyTrayIcon Empathy tray icon flashes Juliet clicks on tray icon and chooses Accept Empathy tray icon calls HandleWith('org.freedesktop.Telepathy.Client.EmpathyChat') ChannelDispatchOperation emits Closed (At or before this point, the CD must wait for all the Observers to return from ObserveChannels if they have not already done so) CD calls HandleChannels on Empathy chat process (service-activating it if needed)
Juliet receives a message from Romeo after a pause in their conversation.
Current implementation, dis2impl1: it arrives in the Text channel
Potential problem: if the chat UI is not currently visible, as currently implemented it cannot necessarily use the same mechanism to notify the user that would be used for a new channel, because it doesn't "own" the notification mechanism for the new-channel case
Proposed solution: if the the chat UI is in the same process as the notification mechanism, all is good - it can prod the notifier directly. If it's not, then it can use a D-Bus API outside the scope of this spec to do the same. (Avoiding premature generalization and assuming clients to be competent)
Juliet receives a message from Romeo after her chat UI has crashed.
Current implementation: it arrives in the Text channel, which nothing is handling, and is lost
Proposed implementation: when a ChannelHandler that was handling a channel falls off the bus, the channel dispatcher closes the channel. If the channel is of type Text, it restarts when the new message arrives.
After a pause in a conversation with Romeo, Juliet closes the IM window or tab. She then receives another message from Romeo, resuming the conversation.
Incorrect implementation, dis3impl1:
Problems with dis3impl1:
Current implementation in Empathy, dis3impl2:
Problems with dis3impl2:
Alternative implementation, dis3impl3:
Problems with dis3impl3:
Proposed implementation: keep dis3impl2, and later use conversation thread IDs as per req27 to solve the problem above
While talking to Romeo in one IM window or tab, Juliet receives a message from him in a separate "thread" of conversation.
Current implementation: impossible on protocols where 1-1 chats are not just a special case of ad-hoc chatrooms, since we guarantee uniqueness per (handle type, handle, channel type) for all handle types except NONE
Proposed implementation:
Romeo is invited to a named chatroom by Mercutio.
Current implementation:
NewChannel (Text, ROOM, handle("The Capulets' ball"), suppress_handler=FALSE) Mission Control runs filters, which include a notification icon in the system tray When the tray icon is clicked, Mission Control continues processing filters and eventually dispatches to the channel handler The channel handler moves Romeo from local-pending to members.
Problems and variations: same as dis1
Proposed implementation:
CM emits Requests.NewChannels([(channel_path, { '...ChannelType': '...Text', '...TargetHandleType': ROOM, '...TargetHandle': 123, '...TargetID': 'ball@conference.capulet.example.com', '...Requested': FALSE, '...InitiatorHandle': 6543, '...InitiatorID': 'mercutio@example.com', ... }, )]) In response, CD calls ObserveChannels on all matching Observers, including org.freedesktop.Telepathy.Client.EmpathyLogger CD creates a ChannelDispatchOperation CD calls AddDispatchOperation on all matching Approvers, including org.freedesktop.Telepathy.Client.EmpathyTrayIcon Empathy tray icon flashes Romeo clicks on tray icon and chooses "Join room" Empathy tray icon calls HandleWith('org.freedesktop.Telepathy.Client.EmpathyChatroom') ChannelDispatchOperation emits Closed (At or before this point, the CD must wait for all the Observers to return from ObserveChannels if they have not already done so) CD calls HandleChannels on Empathy chat process (service-activating it if needed)
Benvolio connects to an irssi-proxy, bip or other IRC bouncer running on some colo box somewhere. The proxy informs his client that he is already in #telepathy and #farsight.
Current implementation: same as dis7, but Benvolio is already in the members set for those channels.
Problems:
Issues to bear in mind:
Proposed implementation:
Romeo receives a VoIP call from Juliet. He answers.
Current implementation: similar to dis1, but the channel has type StreamedMedia, handle type NONE and handle 0; all the UI components must investigate the channel's Group interface to find out who's calling.
Problems:
Proposed implementation:
CM emits Requests.NewChannels([(channel_path, { '...ChannelType': '...Text', '...TargetHandleType': CONTACT, '...TargetHandle': 6, '...TargetID': 'juliet@capulet.example.com', '...Requested': FALSE, # and perhaps... '...InitiatorHandle': 6, '...InitiatorID': 'juliet@capulet.example.com', ... }, )]) In response, CD calls ObserveChannels on all matching Observers, including org.freedesktop.Telepathy.Client.EmpathyLogger CD creates a ChannelDispatchOperation CD calls AddDispatchOperation on all matching Approvers, including org.freedesktop.Telepathy.Client.EmpathyTrayIcon Empathy tray icon flashes Romeo clicks on tray icon and chooses Answer Empathy tray icon calls HandleWith('org.freedesktop.Telepathy.Client.EmpathyVoIP') ChannelDispatchOperation emits Closed (At or before this point, the CD must wait for all the Observers to return from ObserveChannels if they have not already done so) CD calls HandleChannels on Empathy VoIP process (service-activating it if needed)
Romeo receives a VoIP call from Juliet. He does not answer, and Juliet eventually gives up and cancels the call.
Current implementation: as for dis8
Problems:
Proposed implementation:
CM emits Requests.NewChannels([(channel_path, { '...ChannelType': '...Text', '...TargetHandleType': CONTACT, '...TargetHandle': 6, '...TargetID': 'juliet@capulet.example.com', '...Requested': FALSE, # and perhaps... '...InitiatorHandle': 6, '...InitiatorID': 'juliet@capulet.example.com', ... }, )]) In response, CD calls ObserveChannels on all matching Observers, including org.freedesktop.Telepathy.Client.EmpathyLogger CD creates a ChannelDispatchOperation CD calls AddDispatchOperation on all matching Approvers, including org.freedesktop.Telepathy.Client.EmpathyTrayIcon Empathy tray icon flashes Time passes, Juliet gives up and hangs up the call CM emits ChannelClosed(channel_path) ChannelDispatchOperation emits Closed
Problems remaining:
Romeo logs on to an IM service. As part of the connection process, contact list channels for the various predefined CONTACT_LIST handles, e.g. subscribe, are created automatically by the connection manager, as specified by the Telepathy API.
Current implementation:
NewChannel (ContactList, LIST, handle("subscribe"), suppress_handler=FALSE) Mission Control dispatches to the channel handler
Problems:
Proposed implementation:
Romeo logs on to an IM service. As part of the connection process, contact list channels are created automatically by the connection manager for all the GROUP handles he has previously defined, as specified by the Telepathy API.
Current implementation:
NewChannel (ContactList, GROUP, handle("Montagues"), suppress_handler=FALSE) Mission Control dispatches to the channel handler
Problems addressed by proposed implementation:
Proposed implementation dis12impl1:
Problems remaining:
Romeo is connected to the same XMPP account using his PC and his N800. He uses the PC to create a contact group, "My true love", and adds Juliet to it. On the N800 he expects the new group to appear automatically.
Current implementation:
NewChannel (ContactList, GROUP, handle("My true love"), suppress_handler=FALSE) Mission Control dispatches to the channel handler
Problems: same as dis12
Possible solution: same as dis12
Juliet receives a message from Romeo using MSN, in which "1-1" conversations are actually ad-hoc chatrooms with exactly two members. She would like this to be indistinguishable from Romeo sending her a message over XMPP, in which 1-1 conversations are really 1-1.
Current implementation:
NewChannel (Text, NONE, 0, suppress_handler=FALSE) The channel is passed through filters, etc.
Problems:
Romeo receives an invitation to join an ad-hoc chatroom currently containing Mercutio and Benvolio.
Current implementation:
NewChannel (Text, NONE, 0, suppress_handler=FALSE) The channel is passed through filters, etc.
Problems:
Mercutio is talking to Benvolio in a 1-1 chat. Benvolio upgrades the chat to a chatroom in order to invite Romeo to join in.
Current implementation: none
Juliet is talking to Romeo using a text or VoIP UI when he sends her a file in the context of that conversation. If it implements file transfer functionality, the text or VoIP UI should handle the file transfer; otherwise, the channel dispatcher should fall back to launching a standalone file transfer handler.
Proposed implementation and problems: same as dis5
Juliet is not interacting with Romeo when he sends her a file. Some appropriate UI needs to be launched to indicate that the file has been offered.
Proposed implementation: same as dis1
File transfers might be a useful model for collaborative applications to use to transfer snapshots of state, or to transfer related files (e.g. in a word processor, you could receive an inline image that is embedded in the document). This is much like dis6.
Additional problems: if the file transfer is part of the word processor's IPC mechanism, then it really wants to get the file transfer, rather than having another process get it as a result of a situation like dis5c.
Proposed implementation: Don't do this.
An applet displays all file transfers made using Telepathy, Firefox, etc.
Proposed implementation: it's an Observer for all file transfers
An OLPC Activity instance encapsulates an instance of an application, zero or more D-Bus tubes and zero or more stream tubes to transfer messages or state between participants, and a text chatroom to discuss the activity.
In the "1.0" protocol used in early 2008, each Activity instance is backed by an XMPP or Clique MUC (chatroom).
Current implementation: we assume that the channels (Tubes, ROOM, foo) and (Text, ROOM, foo) correspond 1:1. Activity discovery is done out-of-band using OLPC-specific extensions, although we'd like to make some of it more standard (mainly invitations).
Problems:
Proposed implementation:
Tybalt asks Juliet to help him fix a problem with his computer, and offers her a VNC connection to his computer so she can interact with his desktop.
Romeo offers Mercutio and Benvolio access to an OpenArena server running on his local computer.
Proposed implementation:
Rosalind has blocked messages and calls from Romeo. However, her IM service does not support server-side blocking, so her client must implement blocking on the client side.
(A similar approach can be used to implement other privacy models, such as "only allow messages from contacts on my publish list".)
Current implementation: a filter in Mission Control 4.x
Proposed implementation: a filter (dlopen()ed or hard-coded) in Mission Control 5.x - we do not propose to allow this sort of thing over D-Bus
(From Frederic Peters on the mailing list)
Frederic wants to see IM messages appear as some sort of overlay when Totem is running full-screen.
Problems:
Proposed implementation:
A Telepathy gnome-panel applet needs to be able to indicate incoming calls or channels. The Empathy contact list window should also be able to indicate incoming calls or channels, e.g. by highlighting the contact.
Proposed implementation: they're both Approvers
(From the Nokia Internet Tablets, but also generally applicable)
Naba's Internet tablet dims the screen when not in use. When a message or call comes in, the screen backlight should come up to normal brightness.
Current implementation: a filter in Mission Control 4.x?
Problems: is this really just a special case of dis24?
Proposed implementation: either a filter in Mission Control 5.x, or the device-state service (which handles the backlight) can be made an Observer
Romeo has both Kopette and Empathy installed on his system and both clients are able to handle text channels. Romeo wants to be able to choose between kopette and empathy just like he can choose between epiphany and firefox to handle http urls (see gnome-default-applications-properties).
Problems:
Proposed implementation:
Problems remaining:
Romeo has both Empathy and Elisa installed. When elisa is running fullscreen he wants it to handle outgoing and incoming calls, otherwise he wants empathy to handle them.
Problems:
Proposed implementation:
A monolithic Telepathy client on a resource-constrained platform responds to new channels without the help of a channel dispatcher implementation.
Current implementation: the client sets suppress_handler=TRUE on all its channel requests, and ignores NewChannel signals that have suppress_handler=TRUE
Proposed implementation: a straightforward port of the current implementation
The channel dispatcher crashes. Some other component (probably a UI) notices and restarts it. The channel dispatcher must reconcile its internal state with what's actually going on.
It is likely that the channel dispatcher and the account manager are in fact the same process (Mission Control and Decibel are both implemented like this), so we must be able to cope with a simultaneous CD and AM crash.
Current implementation: Nokia's Mission Control 4 calls Disconnect on all connections, causing reality to reflect its internal state. Obviously, this isn't ideal (and can cause messages to be lost).
Proposed implementation: The channel dispatcher discovers existing connections and channels, causing its internal state to reflect reality.
More specifically:
The NewChannels signal carries 2 or more channels. One or more of these channels, but not all of them, emit Closed before the CD has a chance to invoke some or all of the Clients.
Current implementation: Nokia's Mission Control 4 supports dispatching of only one channel at a time, and if that channel is closed, the operation is aborted (i.e., clients don't even see the channel).
Proposed implementation: the CD behaves as if nothing happened, and happily dispatches the channels (including the dead ones) to the clients.
Problems addressed: