Activity sharing

Telepathy

Libtelepathy is a system describing a generic interface for multi-user chat (MUC), instant messaging (IM) and voice/video applications. It is the underlying infrastructure used by Sugar.

The generic telepathy interface specification can be found at http://telepathy.freedesktop.org/

Presenceservice

The presenceservice is a part of Sugar that tracks other Buddies and Activities on the network. It is designed to have a Dbus interface that is to be used by applications. To make life easier, though, there is a class that takes care of talking to the Dbus presenceservice: (sugar.presence.PresenceService. In fact, you'll probably only have to use that.

Currently the presenceservice uses Gabble, a telepathy 'Connection Manager' that provides server-based Jabber/XMPP functionality. It talks to a server (olpc.collabora.co.uk) and sets up different chat rooms through which activities talk to each other. It is therefore not ideal yet, and will be replaced by Salut, a link-local Connection Manager. This will also support multi-casting to improve network performance.

Tubes

Tubes offer a mechanism to provide a Dbus service that is shared between several different nodes in a network. They are part of libtelepathy as well. There is currently only one implementation within telepathy that supports Tubes: Gabble (used by the presenceservice), so all tube connections currently require a chat-room on a server. Once a tube is available, it functions as a Dbus bus (like the session and system busses) that is shared between the different nodes.

Using tubes in Sugar activities

To use a tube the following actions are necessary:

1. Create a Connection Manager object (Gabble)
2. Get a Connection object (to the Collabora server)
3. Get a Tubes channel
4. Create or join a Tube

Step 1 and 2 get taken care of by Sugar, and step 3 and 4 will probably be in the future as well. However, currently it is a little bit of work to perform these. Once an activity is shared, a tubes channel should be created in case there is none (presence service doesn't set this up yet). The initiator of the activity should then call Tubes.OfferTube to offer a Tube with a specific service name. When a buddy joins an activity, he will try to figure out which Tubes are available by calling Tubes.ListTubes() on the tubes channel (which he doesn't have to create anymore). Both OfferTube and ListTubes result in a callback when the Tube becomes really available. Only then a working Tube is handed to the (shared) activity and it is possible to export objects on that bus and subscribe to signals etc.

Sharing an object through the tube

The class you want to share should inherit from dbus.service.Object. Once you have the tube:

   dbus.service.Object.__init__(self, self._tube, self._object_path)

Calling a function on a remote object

Once you know the tube and the unique busname:

   self._tube.get_object(busname, self._object_path).MyFunction(123)

Subscribing to a signal

   self._tube.add_signal_receiver(self._receive_my_sig, 'MySignal', \ 
       IFACE, path=self._object_path, sender_keyword='sender') 

Who's who?

Buddies/nodes within an activity are currently identified with different handles by different components. The following handles can be distinguished:

• Dbus name. If you have a Dbus related function with the “sender” argument specified, this is what you'll get. To buddy object:

   sugar.presence.PresenceService.get_buddy(buddy's publiic key)

• Telepathy handle. To buddy object:

   sugar.presence.PresenceService.get_buddy_by_telepathy_handle(tp_conn, tp_conn_path, handle)