[Telepathy] New channel request/announcement/dispatch interfaces

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 20 Mar 2008 at 13:28:19 +0000, Simon McVittie wrote:
> Rob and I have come up with the following design:
> 
> * channels are not necessarily unique per (channel type, handle type,
>   handle) any more - necessary for proper support of XMPP message threads
>   and "call IDs"/dialogs on SIP text messages, and very useful for
>   collaborative apps using Tubes on the desktop
> 
> * channels can be grouped somehow (this is necessary for Tubes and probably
>   useful for file transfers)
> 
> * grouped channels that open at the same time are signalled together
> 
> * grouped channels are dispatched together (this is necessary for OLPC
>   (if they ever use MC, which I'd like) and for collaborative apps using
>   Tubes on the desktop)
> 
> * channels are announced with an a{sv} of (D-Bus core) properties, including
>   handle type, handle, channel type, ... but potentially also others
> 
>   - only properties which are immutable can be mentioned, to avoid races
>   - this reduces the amount of bootstrapping necessary to go from an
>     announcement to a channel with all its properties (fewer round trips)
> 
> * capabilities interface is extended to catch up

So, I've been looking at this some more. It turns out to be quite hard,
so I'm going to brainstorm stuff on the mailing list and try to pick up
some feedback.

Below, "MC" or "Mission Control" refers specifically to Nokia's Mission Control
implementation (as seen in Maemo and at mission-control.sf.net), while
ChannelDispatcher refers to the channel dispatcher component that
needs its API designed next - the initial implementation will be in
Mission Control, but hopefully Decibel can support it too.

(Due credit: the name, and the concept of dividing "mission control" into
potentially independent components, are from Decibel - thanks, Tobias! I'll
investigate the Decibel API and see whether we can pick up its
ChannelDispatcher API as-is or with relatively small changes.)

Also, I'm using Empathy and AbiWord as placeholders for "a Telepathy UI"
and "a collaborative application that can use Telepathy".

Here are some of the situations where we see "bundling" channels as
important.

* Tubes on the desktop. If you're doing collaborative editing in
  AbiWord (which is backed by an XMPP chatroom), you don't really want
  that chatroom to appear in Empathy - you want it to appear embedded
  into your AbiWord window. Ideally, you'd be able to have a voice/video
  chat about the document going on at the same time, and have that as
  some sort of pane in your AbiWord window too.

  (On OLPC, we have a sort of half-hearted prototype of this, where it
  is implicitly assumed that each XMPP chatroom corresponds to a
  particular "Activity", and the Text and Tubes channels are dispatched
  together. At the moment it uses OLPC-specific out-of-band information
  to do this, though.)

* Adding Tubes (or whiteboarding, or ...) to an existing conversation or
  chatroom

  This is likely to be rather hard :-( We might need to extend the
  ChannelHandler API to optionally support having the channel stolen by
  another handler (so Empathy can gracefully hand over the chatroom to
  AbiWord). Or, we could declare this use-case to be unsupported and
  move on...

* File transfers. The new MessageParts interface allows "attachments"
  which are not actually attached but are downloaded separately (which might
  be a useful representation for MSNP2P stuff). The file transfer
  channels for these (and in fact, probably file transfers in general)
  ought to be "associated with" the Text channel.
 
* Delivery reporting and non-textual message parts.

  My first draft of the MessageParts interface had "basically text" messages
  (including text with formatting, or custom smileys, or whatever) sharing the
  pending-message queue with delivery reports (which do not necessarily
  contain properly localized text) and non-textual messages (which have
  no text part); only messages with a text part got signalled in the
  Text interface.
  
  However, this would mean that in non-MessageParts clients, the non-Text
  pending messages queued up indefinitely, which would be bad. I've
  addressed this in the latest draft by making DeliveryReporting a
  separate channel, which can (hopefully) be rejected if nothing supports it.

Originally, I thought that the way forward was to have an object
representing a "bundle" of channels. However, I'm now leaning more towards
having "secondary channels" optionally point to a "main channel" - this
would simplify dispatching to:

- - the main channel is dispatched
- - its secondary channels are offered to the same channel handler, if it
  implements some new MultipleChannelHandler interface
- - if the main channel's handler doesn't want them, the secondary
  channels are dispatched as usual (this lets chatrooms get handled by
  Empathy if AbiWord doesn't know how)

which seems a rather saner approach.

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFH/ilpWSc8zVUw7HYRAssDAKC7r4efsnGOOPH5RLzjzSVWAczN6wCfeqow
zaYKTBVNASQaNbN4SPgM8X4=
=hXDa
-----END PGP SIGNATURE-----