Collaboration Tutorial/lang-es

Este tutorial se enfoca en compartir actividades. Lee Activity sharing para una revision de conceptos. Tambien checa Presence Service and yTubes.

Ver Collaboration Central para todas las cosas relacionadas con colaboración de actividades.

Introducción

La colaboración es implementada por Telepathy, un marco de trabajo (framework) implementado por D-Bus para protocolos de mensajería instantanea (como Jabber). El Presence Service provee funcionalidades a Sugar para seguir actividades y amigos (tal como se muestra en la vista de vecindario), y habla al manejador de conexiones de Telepathy para XMPP via un servidor Jabber (telepathy-gabble), y vincula localmente via XMPP (telepathy-salut).

XMPP es usado para proveer información de presencialidad de los amigos (otras XOs que se pueda colaborar). La vista de malla es como una lista de amigos, representada de una forma mas gráfica.

NNo todos los amigos que veras son de la misma red en la cual esta. De forma particular, cualquiera de estas puede estar detras de un firewall de NAT, asi que no puedes estar detraas de un cortafuego NAT, así que simplemente se puede abirr el socket TCP/IP para que intercambie información. Furthermore, while it is not yet implemented, Bitfrost's P_NET protection will restrict activities' use of networking, but not apply to collaboration via Telepathy.[1]

XMPP via the Jabber server on the school server allows you to exchange data with all the Buddies you can see, whether or not they are directly reachable from your XO.

Actividades compartidas

Una actividad compartida es implementada usando XMPP MUC (cuarto de chat multiusuario). Los amigos en el cuarto, estan en las actividades compartidas.

El servicio de presencia provee cada actividad compartida con un canal de texto de Telepathy por defacto. Este canal de texto es una conexión al cuarto de chat XMPP, pero no es util para compartir datos directamente. Puede ver un ejemplo de estos canales de texto en uso directo a la actividad Chat. En el futuro Sugar proveera una "capa de chat" a las actividades, permitiendo hacer el chat de texto con los participantes de las actividades compartidas.

Sobre este canal de Texto, PS provee un canal de Tubos, para intercambiar datos con otros participantes via estos Tubos.

Tubos

Existen dos tipos de Activity sharing#Tubes actualmente: tubos D-Bus y de trasmisión.

D-Bus Tubes provide D-Bus functionality to signal and call methods on everyone in the room.

Stream Tubes wrap TCP/IP sockets and are more suited to streaming data between two participants.

Tubos de D-Bus

Ver el tutorial de D-Bus y el tutorial dbus-python.

D-Bus prvee señales y métodos:

• Señales son multitransmisión - they are sent to all participants in the shared activity (including the sender). They send data and have no return value.
• Las llamadas de metodo son llamados a un participante unico, y estas si tienen un valor de retorno.

It is important to design your Activity's D-Bus Tubes API well, to support the functionality that your collaboration will need.

More to come here...

Nombres de bus, pseudonombres, objetos de amigos

Signals and Methods use bus names to identify senders and recipients. Telepathy uses handles to identify participants. Sugar uses Buddy objects.

The TubeConnection object can convert between bus names and handles - see tubeconn.py for details.

Más proximamente...

Tubos de transmision

Ver el código de la actividad de Read como referencia. Es en git://dev.laptop.org/projects/read-activity y se lleva de forma predeterminada en sugar-jhbuild.

Más proximamente...

Ejemplo de Actividad: HelloMesh

HelloMesh es un demo de activades con codigo de ejemplo usando un tubo D-Bus. El codigo esta en git://dev.laptop.org/projects/hellomesh y puedes construir una compilacion de sugar con ./sugar-jhbuild buildone hellomesh

Primero, vamos a mirar los Tubos de D-Bus en su API usando HelloMesh. Existen dos señales y un metodo:

   @signal(dbus_interface=IFACE, signature=)
   def Hello(self):
       """Say Hello to whoever else is in the tube."""
       self._logger.debug('I said Hello.')

   @method(dbus_interface=IFACE, in_signature='s', out_signature=)
   def World(self, text):
       """To be called on the incoming XO after they Hello."""
       if not self.text:
           self._logger.debug('Somebody called World and sent me %s',
                              text)
           self._alert('World', 'Received %s' % text)
           self.text = text
           self.text_received_cb(text)
           # now I can World others
           self.add_hello_handler()
       else:
           self._logger.debug("I've already been welcomed, doing nothing")

   @signal(dbus_interface=IFACE, signature='s')
   def SendText(self, text):
       """Send some text to all participants."""
       self.text = text
       self._logger.debug('Sent text: %s', text)
       self._alert('SendText', 'Sent %s' % text)

When a new participant joins the shared activity, it sends the Hello signal. This goes to all existing participants. The Hello signal has an empty signature, since no actual parameters are being sent.

When an (existing) participant receives the Hello signal, it calls the World method of the signal's sender. The World method takes a string parameter (text) represented by

in_signature='s'

It doesn't return anything, hence

out_signature=''

Calling World when Hello is received is done in hello_cb:

   def hello_cb(self, sender=None):
       """Somebody Helloed me. World them."""
       if sender == self.tube.get_unique_name():
           # sender is my bus name, so ignore my own signal
           return
       self._logger.debug('Newcomer %s has joined', sender)
       self._logger.debug('Welcoming newcomer and sending them the game state')
       self.tube.get_object(sender, PATH).World(self.text,
                                                dbus_interface=IFACE)

Note that signals go to all participants, including yourself - the above code shows how to ignore your own signals.

sender is a bus (as in D-Bus) name, like :2.OWI0MTk2MzNAdmFpbwAA. Signals and Methods use these to identify senders and recipients.

In order to receive the Hello signal, we need to add a signal receiver:

   def add_hello_handler(self):
       self._logger.debug('Adding hello handler.')
       self.tube.add_signal_receiver(self.hello_cb, 'Hello', IFACE,
           path=PATH, sender_keyword='sender')
       self.tube.add_signal_receiver(self.sendtext_cb, 'SendText', IFACE,
           path=PATH, sender_keyword='sender')

You can see this called in the World method above, because in this example once we have had our World method called by an existing participant, we can then respond to somebody else's Hello signal.

This also adds a signal receiver for the SendText signal, defined above, which sends the text from the user interface.