Collaboration Tutorial/lang-es: Difference between revisions
(Created page with 'Este tutorial se enfoca en compartir actividades. Lee Activity sharing para una revision de conceptos. Tambien checa Presence Service and yTubes. Ver [[Collaboration…') |
|||
Line 4: | Line 4: | ||
== Introducción == |
== 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 [[servicio de presencia |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|telepathy-gabble]]), y vincula localmente via XMPP ([[Telepathy Salut|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. |
|||
Collaboration is implemented with [[Telepathy]], a D-Bus framework for Instant Messaging protocols. The [[Presence Service]] provides functionality to Sugar to track shared Activities and Buddies (and show them on the Neighborhood View), and talks to Telepathy connection managers for XMPP via a Jabber server ([[Telepathy Gabble|telepathy-gabble]]), and Link Local XMPP ([[Telepathy Salut|telepathy-salut]]). |
|||
⚫ | 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 [[OLPC Bitfrost#P_NET: network policy protection|P_NET]] protection will restrict activities' use of networking, but not apply to collaboration via Telepathy.[http://lists.laptop.org/pipermail/devel/2008-June/015291.html] |
||
XMPP is used to provide presence information about Buddies (other XOs you can collaborate with). The mesh view is like an instant messenger buddy list, represented in a more graphical way. |
|||
⚫ | |||
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. |
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. |
||
Line 15: | Line 14: | ||
=== Actividades compartidas === |
=== 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. |
|||
Presence Service provides each shared activity with a Telepathy Text Channel by default. This text channel is a connection to the XMPP chat room, but is not useful for data sharing directly. You can see an example of this Text Channel in direct use in the [[Chat]] activity. In future, Sugar will provide "overlay chat" to activities, allowing you to do text chat with the participants of a shared activity. |
|||
Sobre este canal de Texto, PS provee un canal de Tubos, para intercambiar datos con otros participantes via estos Tubos. |
|||
On top of this Text Channel, PS provides a Tubes channel to exchange data with the other participants via Tubes. |
|||
=== 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. |
D-Bus Tubes provide D-Bus functionality to signal and call methods on everyone in the room. |
||
Line 31: | Line 30: | ||
=== Tubos de D-Bus === |
=== Tubos de D-Bus === |
||
Ver el [http://dbus.freedesktop.org/doc/dbus-tutorial.html tutorial de D-Bus] y el [http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html tutorial dbus-python]. |
|||
D-Bus |
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. |
|||
* Method calls are called on a single participant, and they do have a return value. |
|||
'''It is important to design your Activity's D-Bus Tubes API well, to support the functionality that your collaboration will need.''' |
'''It is important to design your Activity's D-Bus Tubes API well, to support the functionality that your collaboration will need.''' |
||
Line 47: | Line 46: | ||
The TubeConnection object can convert between bus names and handles - see [http://dev.laptop.org/git?p=sugar;a=blob;f=lib/sugar/presence/tubeconn.py;h=b487391f862fc6fbaf789cbf25e53fd0676b2df0;hb=HEAD tubeconn.py] for details. |
The TubeConnection object can convert between bus names and handles - see [http://dev.laptop.org/git?p=sugar;a=blob;f=lib/sugar/presence/tubeconn.py;h=b487391f862fc6fbaf789cbf25e53fd0676b2df0;hb=HEAD tubeconn.py] for details. |
||
'' |
''Más proximamente...'' |
||
=== Tubos de transmision === |
=== 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 == |
== Ejemplo de Actividad: HelloMesh == |
Revision as of 20:10, 28 June 2011
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 is a demo activity with sample code using a D-Bus Tube. The code is in git://dev.laptop.org/projects/hellomesh and can be built in sugar-jhbuild with ./sugar-jhbuild buildone hellomesh
First, let's look at HelloMesh's D-Bus Tubes API. There are two signals and one method:
@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.