Collaboration Tutorial/lang-es

From OLPC

Jump to: navigation, search

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.

Contents

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.

Los Tubos D-Bus proveen la funcionalidades para señalar y llamar los metodos para todos en los cuartos.

Las señales de Tubos se transmiten por sockets en TCP/IP y estan ajustados a transmitir datos entre dos participantes.

Tubos de D-Bus

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

D-Bus prevee 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.

Es importante diseñar tus actividades con Tubos de D-BUS usando el API tambien, para soportar la funcionalidad que se necesitara en tu funcionalidad colaborativa.

Continuará...

Nombres de bus, pseudonombres, objetos de amigos

Señales y Metodoos usan nombres de bus para identificar al emisor y sus receptores. Telepathy usa sobre nombres para identificar a los participantes. Sugar usa objetos de amigos (Buddy objects).

Los objetos de TubeConnection pueden convertir entre los nombres de bus y los sobre nombres, - ver tubeconn.py para mas ayuda.

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)

Cuando un participante se une a una actividad compartida, envia la señal Hello. Esta señal va para todos lso participantes. La señal Hello tiene una firma vacia, ya que no los parámetros actuales se están enviando.


Cuando un particpante (existente) recive la deñasl Hello, llama all metodo World de la señal de quein la envio. El metodo World toma un parametro de cadena (texto) representado por
in_signature='s'
No regresa ningún valor, por lo tanto
out_signature=''

Llamando al metodo World cuando Hello es recibido es hecho en 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)

Nota que la señal va a todos lso participantes, incluyendo a ti mismo - el codigo mostrado arriba muestra como ignorar tus propias señales.

quien envia es un nombre de bus (como en D-Bus), como :2.OWI0MTk2MzNAdmFpbwAA. Señales y Metodos usados para identificar quien envia y quien recive.

Para poder recibir la señal Hello, necesitamos agregar una señal de recepción:

   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')

Puedes ver esta señal es llamada en el metodo World de arriba, una vez hecho este ejemplo tendremos la llamada a nuestro metodo World desde un participante existente, podremos responder a alguien mas con la señal Hello.

Tambien agregua una señal de recepción para la señal SendText, definida arriba, quien envia el texto desde la interfaz de usuario.

Personal tools
  • Log in
  • Login with OpenID
About OLPC
About the laptop
About the tablet
Projects
OLPC wiki
Toolbox
In other languages