Tubes: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
mNo edit summary
Line 1: Line 1:
:'''''See [[Low-level_Activity_API#Tubes]].'''''
:'''''See [[Low-level_Activity_API#Tubes]].'''''


{{stub}}
{{cleanup}}
=Data transfer via Telepathy=
=Data transfer via Telepathy=


Line 38: Line 36:
*[[Presence Service DBus API]]
*[[Presence Service DBus API]]
*[[Software_projects#Telepathy_.28Networking.29]]
*[[Software_projects#Telepathy_.28Networking.29]]

[[category:Telepathy]]
[[category:Collaboration]]
[[category:Developers]]

Revision as of 14:59, 4 February 2008

See Low-level_Activity_API#Tubes.

Data transfer via Telepathy

A tube is a Telepathy primitive for sending and receiving data, which can be to one person or to a group of people. Tubes can carry reliable byte streams or unreliable datagrams by analogy to TCP or UDP. When a tube is to a group, some different semantics may be more appropriate, since a shared stream is not coherent. It is up to the connection manager how tubes are implemented on top of its protocol.

There are two types of Tubes at present: D-Bus Tubes and Stream Tubes.

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.

D-Bus Tubes

A multi-user tube is represented as a D-Bus bus, and the connection manager makes a mapping between the participants in the tube and D-Bus bus name. Clients can then take advantage of D-Bus's serialisation and the bindings so that they have to do less protocol work.

Tubes Channel Type

In terms of the Telepathy API, we have created a channel type which has methods for enumerating existing tubes and requesting new ones. The channel might be attached to an existing channel (such as a MUC), in which case it will be automatically closed when the underlying channel is closed.

More on Tubes

Tubes protocol (discussion)

Dafydd Harries on Tubes

Rob McQueen's blog


See also