[Telepathy] [Fwd: Re: tp-qt4 Requesting channels using ChannelDispatcher high-level API proposal]

[Simon McVittie]

Matt Rogers wrote:
> But I question putting the implementation of a draft specification (at  
> least according to the page you linked) over adding more core  
> telepathy functionality (like connection managers).

All interfaces start off as a draft... I'm undrafting the channel dispatcher
interfaces at this very moment! "Draft" doesn't mean it's unimportant, just
that it's not necessarily finished and stable.

(We have a full implementation of the AccountManager and ChannelDispatcher,
Mission Control 5.x, of which the first non-beta release was last week;
Empathy will start to be ported to use the AccountManager and
ChannelDispatcher soon. Meanwhile, telepathy-qt4 has nearly full client
bindings, and I'm writing skeletal client bindings in telepathy-glib now.)

> Is there a reason why you're focusing on this over other things?

Without the AccountManager and ChannelDispatcher, Telepathy's scope is, in
practice, limited to things that traditional monolithic IM clients could do
(i.e. "basically Pidgin").

That was never meant to be the limit of what Telepathy could do - for instance,
Nokia's series of Maemo internet tablets have always had several cooperating
processes (call UI, chat UI, presence UI) all communicating with Mission
Control and with CMs, rather than a single monolithic client like Empathy.

It was always a goal to be able to do this on the desktop, but obviously more
flexibility and care is needed to have Telepathy integrated into a highly
customizable/extensible desktop like GNOME, KDE, XFCE etc. than into a
relatively fixed platform like Maemo. (In principle, Mission Control 4 as
shipped on Maemo devices was extensible, but in practice its design tends to
fall over if you have more than one UI for a channel type - the
ChannelDispatcher fixes this.)

The account manager and channel dispatcher are the missing piece of central
coordination, taking ideas from Mission Control <= 4 and Decibel. The
AccountManager stores accounts and shares connections, allowing any process to
put an account online without conflict, while the ChannelDispatcher arbitrates
channel handling between processes (ensuring that exactly one process handles
each channel).

This opens the way for better integration of Telepathy throughout the desktop,
particularly in non-traditional contexts like Arnaud Maillet's recent work
on sharing VNC sessions over Tubes by modifying Vino and Vinagre. It would also
enable "traditional" clients like Empathy to be split into several
loosely-coupled components (more like the proprietary UIs on Maemo), which
would work properly even if you have (for instance) a GNOME client and a
KDE client installed on the same machine.

The AccountManager design comes fairly directly from a mixture of the
account management functionality in Mission Control 4 and in Decibel, while a
large number of use cases for the ChannelDispatcher design (which is by far
the harder part) are explained in the doc/ directory of telepathy-spec.

So, yes, we believe this is crucial to the future of Telepathy. (Also, a lot
of the work has already been done :-)

    Simon