Hi,
The org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities
interface gives you the channel classes your contact supports. But it
does not tell you whether the contact is ready to handle the channel
class and that the application handling this channel class is running
on your contact's computer. There is some use-cases where it is useful.
== Use-case: rhythmbox, listen your contacts' music. ==
On a local network with Avahi and without Telepathy, Rhythmbox' DAAP
plugin shows the list of people who actually share their music. It does
this when Rhythmbox (or another DAAP sharing application) is running on
people's computer on the local network. In order to do the same on XMPP
with Telepathy, the ContactCapabilities interface is not enough because
it only tell you that your contacts have a DAAP application installed
on their computer but not that it is running. Of course you could still
connect on your contact's DAAP share with a backward stream tube, and
the DAAP application (Rhythmbox) could be started by the Channel
Dispatcher on your contact's computer. But it would be better if the
information 'now running' is available. So I could have a good
Rhythmbox UI where the sidebar contains the Telepathy sources, i.e. the
few contacts sharing music at the moment, and a less visible option in
the menu (or wherever it makes sense) to connect to a contact's music
library if that contact is not running the DAAP server at the moment.
== Use-case: games ==
There is a similar use case for games: even if all your contacts
support the go game, it is more likely that you want to play with a
contact who has already started a go application. So it worths
displaying thoses contacts in the top of the contact selector, or
whatever the UI is to choose the contact.
== XMPP implementation ==
The existing ContactCapabilities interface does not need to change and
must still use XEP-0115 Entity Capabilities. Rob suggested the new
'now-running' interface use a PEP node instead of overloading the
XEP-0115 Entity Capabilities. This has some advantages: when your
capabilities change, the hash of your capabilities change and every
Jabber client (even not Telepathy ones) has to request your
capabilities and download them. Fortunately, the capabilities don't
change often, but only when you install/uninstall Telepathy-aware
applications. The list of applications running is likely to change more
often, so using a PEP node for that will save bandwidth because 1. only
Telepathy-aware Jabber clients will download the PEP node, and 2. the
Jabber server has the PEP node content, so it does not need to reach
the client (Well I know that XEP-0115 can also let the Jabber server
cache capabilities and their hashes but I don't think it is implemented
in the real world).
The PEP node should not contain the channel classes directly because it
is too Telepathy specific and some properties in a channel class do not
make sense for remote contacts (e.g. Channel.TargetHandle - u). The PEP
node can contain a similar format than the existing one in XEP-0115
Entity Capabilities. For tubes, it is a string like:
http://telepathy.freedesktop.org/xmpp/tubes/$type#$service
== Telepathy spec ==
The Now-Running feature can be a separate interface
org.freedesktop.Telepathy.Connection.Interface.NowRunning or just new
method in the existing ContactCapabilities interface, like:
GetNowRunningCapabilities ( au: handles ) → a{ua(a{sv}as)}
and a signal NowRunningCapabilitiesChanged ( a{ua(a{sv}as)}: caps )
It should also be available through the
o.f.T.Connection.Interface.Contacts interface with a contact attribute
like o.f.T.Connection.Interface.ContactCapabilities.DRAFT/now-running
It would save D-Bus bandwidth to have a separate interface to get
Now-Running channel classes for Telepathy client which are only
interested by regular capabilities because GetContactAttributes()
cannot get only one attribute on an interface.
Publishing what applications are running to your contacts can be a
privacy problem. Applications must be able to choose whether they
publish the fact they are running to the whole contact list and should
not publish it by default without the user's consent. More granularity
can be done using Rich_Presence_Access_Control_Type. The
org.freedesktop.Telepathy.Client.* interface can have a new D-Bus
property to advertise which channel classes can be published to
contacts as running. Mission Control can then merge Client's Channel
Classes which can be published as Now-Running and call a
SetSelfNowRunning on the CM.
== Empathy ==
Empathy can also benefit from the Now-Running interface. When the user
right-click on a contact in the Empathy contact list, we consider it is
bad to have a huge list of possible actions for every channel class,
like send-file, share-my-desktop, share-my-bookmarks, play-go,
play-chess, play-whatever, share-music, etc. It is not a short-term
issue because at the moment there is not a lot of possible actions.
