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. But in the long-term, the Now-Running interface can help to show only meaningful actions in the context of that contact. Cheers, Alban _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy