D-bus Learning (10): telepathy on D-bus [1]: paper discussion

Now we have many identities on the Internet. For example, I have three or four MSN accounts, QQ, GTalk, and web-based blogs and vblogs, in short, there are many. For small-sized mobile phones and MID-sized handheld devices, we cannot open N clients and N webpages like desktop. In fact, we don't care about the software we are using, we only want to find the contact. D-Bus provides the basis for IPC communication. Many mechanisms are built on D-Bus. D-Bus provides the basic channel, and there are many high-level packages on this channel, for specific applications. Telepathy is one of them for char and voip applications. This satisfies our needs, so it is necessary to study it.

Telepathy of wiki provides the following figure:

Telepathy is a flexible and modular communication framework that supports pluggable real-time communication protocols. Use D-Bus as the IPC of different process components. The telepathy client uses the D-Bus API (telepathy-glib) to share connections between multiple clients (such as the presentation of IM and Email applications. It has the following features:

• Real-time: Telepathy supports IM (point-to-point and group), voice calls, and video calls. Like d-bus, telepathy is not suitable for applications that store forwarding, such as sending and receiving emails)

• Integration: Different developers can benefit from these communications, and telepathy can integrate their respective programs.

• Modular: Telepathy components are modular and developers can focus on developing their own components.

According to the information on the Internet, telepathy is developed by NOKIA. Included in maemo of NOKIA. This part is also included in Moblin/MeeGO. XMPP supports most of our common IM protocols, such as Gtalk SIP, MSN, ICQ, OO, Facebook char, AIM, QQ, and IRC. For us, MSN and QQ are the most commercially available products. Nokia also expanded it to telephone communication, such as Voip Skype and 2G/3G Mobile Communication Phone/SMS. It looks very attractive, so it is worth studying carefully to see if it brings surprises. In
Whether or not telepathy is supported in mode. Invisible mode is not very understandable. It may be "diving ". I think these features are not very demanding for handset devices that support Internet access. However, they are an important and valuable application that proves to be well-qualified (^_^ ).

The following are some important materials to learn in the next stage.

Http://telepathy.free?top.org/wiki/setup:: it is about installing moblin, (ubuntu) and fadora, which is used when the package is missing.

Http://telepathy.free?top.org/spec/: d-businterface Definition

Http://telepathy.free?top.org/wiki/system=20overview:framework Structure

Http://people.collabora.co.uk /~ Danni/telepathy-book/: developer Manual

Http://telepathy.free?top.org/doc/telepathy-glib/:telepathy-glibmanual

Http://telepathy.free?top.org/doc/telepathy-qt4/:telepathy-qt4manual

Many materials can be found from the wiki portal.

Telepaphy is a standard (spec) that defines a set of D-Bus interfaces and a bunch of applications (interface specifications, but it is not very clear if the application is included ). In addition to common text chats, including chat rooms, voice calls, video calls, and file transfers, we have defined an IPC communication mechanism, these IM applications are operated to obtain the contact's status and information and trigger a processing.

To read the. manager file, you need to create a proxy object. The. manager file describes the protocols supported by connection management and required parameters. Create a D-Bus Proxy by giving the Connection Manager a unique name.

Here we use the standard language of D-bus to describe. In telepathy, servers are IM applications, and our development program is client. A connection is established for the Connection Manager for the application and the path of the remote interface is provided. A proxy is established. The method of actually operating the remote interface through proxy is used. This step is similar to establishing a connection between the client and a remote interface in D-bus learning.

Proxy = dbus_g_proxy_new_for_name (Conn/* Connection Manager */, "com. wei. test "/* remote bus name */,"/COM/Wei/myobject "/* remote object name */," com. wei. myobject. myinterface "/* remote interface name */);

In the standard D-Bus, there is no. manager, which is defined by telepathy. If we need to use gabble, use the gabble. manager file. We use the remote object name 'org. freedesktop. telepathy. connectionMananger. gabble, the interface path is '/org/freedesktop/Telepathy/ConnectionManager/gabble', establish a connection (the Remote Application's Bus
Well known of name is org. freedesktop. Telepathy. ConnectionManager. gabble ). If the connection fails, D-Bus daemon starts the gabble service using the Gabble. service file. If the connection is established, you can use RequestMethod to call the method.

There are still some new concepts in telepathy. In the IM example, on the interface, we use RequestHandles (1/* 1 is the handle type, 1 = contact */,
['Ur @ jid.org '] */), a [2] is returned, for example, the list of numbers. We can communicate with a number. In this example, the Type 1 indicates is the parameter type in D-Bus, such as u = uint32, au = array of uint32, a (uu) = array of (struct of uint32, uint32 ),
S = string, a {su} = dictionary of (string to uint), aau = array of (array of uint32 ). Then we will request a channel, RequestChannel ('Org. freedesktop. Telepathy. Channel. type. text', 1, 2, true), The first parameter is the interface name, 1 is the handle type, and 2 is the handle. "True" indicates telepathy
Client indicates that you want to obtain the handle of this channel. If the connection manager agrees to your request, it will return a string indicating the path of the D-Bus object. In this way, we create a proxy for the channel object through the connection bus name and the obtained path name, use proxy to call the call method of the channel.

Telepathy compared with the general D-bus, it defines a learning mechanism that enables the client to learn the D-BUS interface of the server, without defining the XML Representation of D-bus at the beginning. If the interface changes after the server is upgraded, the client can automatically adapt to this change. Communication between processes is not modified by a process upgrade or interface modification. In other words, it is intelligent.

Related links:
My Linux articles