Activity sharing

  For Developers

english | español

HowTo [ID# 257845]  +/-

Introducción

Colaborar con las Actividades de Sugar funciona usando un conjunto de servicios que se ejecutan en la laptop, y APIs en los modulos de Python de Sugar que hacen uso de estos servicios. Los servicios principales son el Telepathy connection managers y el Presence Service que los coordina.

Telepathy es un sistema que describe una interfaz generica para varios tipos de comunicación. Es la profunda infraestructura usada por Sugar para comunicarse. Actualmente, dos implementaciones de Telepathy son usadas: Gabble, para Jabber, and Salut para el servir de Jabber (a.k.a. link-local XMPP). El primero se utiliza cuando el servidor de la escuela es inaccesible, este último en caso de una malla simple.

Advertisements and invitations

Shared sugar activities are discovered in two different ways: through broadcast advertisements, and through invitations.

Advertisements are made when the user tells the activity to share itself with the entire network. Anybody on the network can see the activity.

Invitations are send to particular users. Only those users who are sent an invitation see the activity (unless the activity has also been advertised). When Sugar recevies an invitation, it asks the user whether they want to accept or reject it.

Tubes

Tubes are a means for shared activities to exchange data. There are currently two types of tubes:

• D-Bus Tubes provide a D-Bus bus service that is shared between the participants in a shared activity, providing signals to all participants, and methods called on a particular participant.

• Stream Tubes provide a socket-like connection set up via XMPP, for data streaming like HTTP, between two participants.

Using tubes in Sugar activities

The Presence Service creates connection manager objects (Gabble and/or Salut). It gets a Connection object (to the Jabber server in the case of Gabble). PS creates or gets a Tubes channel. For Python Activities, Sugar creates or joins a D-Bus tube automatically.

The initiator of the activity should then call Tubes.OfferDBusTube 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 OfferDBusTube 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.

See Collaboration Tutorial for more on using Tubes.

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 public key)

• Telepathy handle. To buddy object:

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

Interactions

How the various components interact.

Presence Service ⟷ connection manager

• org.freedesktop.Telepathy.ConnectionManager
  • RequestConnection
• org.freedesktop.Telepathy.Connection
  • RequestChannel
• org.laptop.Telepathy.BuddyInfo
• org.laptop.Telepathy.ActivityProperties

activity ⟷ Presence Service

• org.laptop.Sugar.Presence
• org.laptop.Sugar.Presence.Buddy
• org.laptop.Sugar.Presence.Activity

activity ⟷ connection manager

• org.freedesktop.Telepathy.Channel.Type.Tube
  • OfferDBusTube
  • OfferStreamTube