Tubes: Difference between revisions
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
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