[Telepathy] New channel request/announcement/dispatch interfaces

[Simon McVittie]

I'm currently working on replacing large parts of the Telepathy spec
core - following on from MessageParts and DeliveryReporting (which could
be called "Text channel 2.0"), I'm now rethinking the
RequestChannel/NewChannel API. This will also naturally feed into work
on a ChannelDispatcher API that can be implemented by Mission Control
(and hopefully other implementations, like Decibel).

My work so far is at <http://monkey.collabora.co.uk/tp-spec-smcv-requests/>.

The central issues with the current mechanisms are:

* channels identified by properties other than handle type and handle are
  second-class citizens

  - nickname when joining a MUC
    (https://bugs.freedesktop.org/show_bug.cgi?id=13348)
  - server when doing a room list on XMPP
    (https://bugs.freedesktop.org/show_bug.cgi?id=13346)
  - XMPP message threading (unique per (contact, thread-ID) tuple)
  - SIP dialogs/call-IDs associating text messages (similar to XMPP
    message threading, I think?)

* we want to signal additional properties at channel-creation time, to
  minimize the risk of them getting lost

  - incoming/outgoing channel (good for logging)
  - initiator of a call
    (partly addresses https://bugs.freedesktop.org/show_bug.cgi?id=14606)

* file transfers and Tubes are hard to dispatch correctly with the current APIs

  - we should turn them into channels - but then we need a way to
    associate tubes with the chatroom/text channel they're attached to

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

I'll try to expand on this in future emails.

    Simon