Activity sharing: Difference between revisions

From OLPC
Jump to navigation Jump to search
(reverting translation made to wrong page)
 
(34 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{Developers}}
[[Image:shared activites.png|right]]
{{Translations}}
{{TOCright}}
== Overview ==


Collaboration in Sugar activities works using a set of services that run on the laptop, and APIs in the Sugar Python modules that wrap those services. The main services are the '''Telepathy connection managers''' and the '''[[Presence Service]]''' that coordinates them.
==Telepathy==
Telepathy 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.


[[Image:shared activites.png|center]]
The generic telepathy interface specification can be found at http://telepathy.freedesktop.org/


[http://telepathy.freedesktop.org/ Telepathy] is a system describing a generic interface for various kinds of communication. It is the underlying infrastructure used by Sugar for collaboration. Currently, two Telepathy implementations are used: [[Telepathy Gabble|Gabble]], for Jabber, and [[Telepathy Salut|Salut]] for serverless Jabber (a.k.a. link-local XMPP). The former is used when the school server is reachable; the latter in the simple mesh case.
==PresenceService==
The [[Presence Service]] is a part of Sugar that tracks other Buddies and Activities on the network. It is designed to have a D-Bus interface that is to be used by applications. To make life easier, though, there is a class that takes care of talking to the D-Bus presence service (sugar.presence.PresenceService). In fact, you'll probably only have to use that.


== Advertisements and invitations ==
The presence service uses two telepathy Connection Managers:


Shared sugar activities are discovered in two different ways: through broadcast advertisements, and through invitations.
* '''Gabble''', that provides server-based Jabber/XMPP functionality. It talks to a [[Jabber server]] (e.g. olpc.collabora.co.uk) and sets up different chat rooms through which activities talk to each other.


Advertisements are made when the user tells the activity to share itself with the entire network. Anybody on the network can see the activity.
* '''Salut''', a link-local Connection Manager using reliable multicast over the local network


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.
The [[Presence Service]] will use Gabble when it has Internet access (a valid IPv4 address) and has connected to a [[Jabber server]], otherwise Salut (but not both at the same time).


==Tubes==
== 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.


[[Tubes]] are a means for shared activities to exchange data. There are currently two types of tubes:
==Using tubes in Sugar activities==
To use a tube the following actions are necessary:
#Create a Connection Manager object (Gabble)
#Get a Connection object (to the Collabora server)
#Get a Tubes channel
#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.


* '''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.
===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)


* '''Stream Tubes''' provide a socket-like connection set up via XMPP, for data streaming like HTTP, between two participants.
===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)


=== Using tubes in Sugar activities ===
===Subscribing to a signal===
self._tube.add_signal_receiver(self._receive_my_sig, 'MySignal', \
IFACE, path=self._object_path, sender_keyword='sender')


The [[Presence Service]] creates connection manager objects (Gabble and/or
==Who's who?==
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:
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:
*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)
sugar.presence.PresenceService.get_buddy(buddy's public key)
*Telepathy handle. To buddy object:
*Telepathy handle. To buddy object:
sugar.presence.PresenceService.get_buddy_by_telepathy_handle(tp_conn, tp_conn_path, handle)
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


[[Category:Sugar]]
[[Category:Sugar]]
[[Category:Developers]]
[[Category:Developers]]
[[category:Telepathy]]
[[category:Collaboration]]

Latest revision as of 00:11, 9 July 2011

  english | español HowTo [ID# 257863]  +/-  

Overview

Collaboration in Sugar activities works using a set of services that run on the laptop, and APIs in the Sugar Python modules that wrap those services. The main services are the Telepathy connection managers and the Presence Service that coordinates them.

Shared activites.png

Telepathy is a system describing a generic interface for various kinds of communication. It is the underlying infrastructure used by Sugar for collaboration. Currently, two Telepathy implementations are used: Gabble, for Jabber, and Salut for serverless Jabber (a.k.a. link-local XMPP). The former is used when the school server is reachable; the latter in the simple mesh case.

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