Activity sharing
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.
Avisos e invitaciones
Las actividades compartidas de Sugar son descubiertas de dos formas diferentes: a través de avisos y a través de invitaciones.
Los anuncios son hechos cuando el usuario le dice a la actividad que se comparta con toda la red. Cualquiera conectado en la red puede ver la actividad.
Las invitaciones se envían a usuarios en particular. Sólo aquellos usuarios a quienes se les envió una invitación pueden ver la actividad (a menos que la actividad también fuerá anunciada). Cuando Sugar recive una invitación, pregunta al usuario si desea aceptarla o rechazarla.
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
