dbus

dbus is a message bus system. It is an 'interprocess communication mechanism'.
why dbus? :-
1. It provides both method call as well as 'signal' based IPC mechanism.
2. Allows communication between 'desktop applications' between same session as well as desktop session and operation system.
3. Any application can come at any time and register with 'dbus daemon' for publishing 'services' and any application can come at any time and subscribe for a given service. Hence provides great IPC flexibility to the applications.

Mechanism? :-
Each application is represented as an object when considered on dbus (e.g. GObject when using glib binding). For addressing, a name is given to each object. Its called 'object path'. Object path could be like '/abc/def' but it can be designed as you may like. Dbus has a heavily tested api. But they recommend using wrappers (e.g. glib) for using dbus functionality. Internally dbus daemon and applications would communicate using sockets. And it is estimated that communication between 2 applications would be twice as slow as direct communication between them. (Makes sense since it would be 2 socket pairs as opposed to 1 in direct communication case)


Example:
I am outlining a glib binding based hello world example for asynchronous signal based communication.

Steps:
1. Describe your object interface (that is interested in providing any services (methods that can be called by other apps or signals that this application will emit) in an XML file.

-node-
-interface name="a.b.ciface"-
-signal name="sig1"-
-arg type="i" name="x" direction="out"-
-arg type="i" name="y" direction="out"-
-arg type="y" name="z" direction="out"-
-arg type="s" name="w" direction="out"-
-/signal-
-/interface-
-/node-

** - assume - to be '<' or '>' in above code. sorry, working on it!!
Here, 'a.b.ciface' is interface name, 'sig1' is the name of signal that your app will emit. x,y,z,w are 'arguments' of your signal. Notice the 'type' field in arguments. Here 'i' is for integer, 'y' is for byte etc. Complete list can be found in dbus specifications [1]. Similarly methods can be described.

2. Generate server and client side header files using 'dbus-binding-tool'
$dbus-binding-tool --prefix=pqr --mode=glib-server app_iface.xml --output=server-stub.h --force
$dbus-binding-tool --prefix=pqr --mode=glib-client app_iface.xml --output=client-stub.h --force

Note that prefix is important and this will be 'prefixed' to your method (stub) name and hence has to be referred accordingly in server/client code.

3. Most of the time, you will have to generate 'stub' for your type signature (for some basic type signatures, in-build functionality is available. Check dev-help [2] before you proceed). e.g. in above interface description, I am sending {long,long,char,string}. The stub (.c and .h) can be generated using a tool called 'glib-genmarshal'. The tool's man page is good resource along with examples to get it done.

4. Now, you are ready to write server and client code. I will just provide basic template here:

-------------------------------------------------------------
Server:
1. initialize g_type - g_type_init()
2. get connection to bus - dbus_g_bus_get()
3. create a proxy object to talk to bus itself - dbus_g_proxy_new_for_name()
4. register your service with dbus bus - dbus_g_proxy_call()
5. create a new g_object - g_object_new()
6. Associate dbus object path with this object - dbus_g_connection_register_g_object()
7. continue your code. whenever you want to fire a signal, call - g_signal_emit()
8. One important step - you have to register stub signature that you created using glib-genmarshal. This has to be done in 'class_init()' function using 'dbus_g_object_register_marshaller'. Refer to example code for this.
-------------------------------------------------------------
There is actually more work to be done. But its better to look at sample code than explain here. So, refer to [3] for detailed example.

-------------------------------------------------------------
client:
1. Get a connection to bus - dbus_g_bus_get()
2. create a proxy object for server object - dbus_g_proxy_new_for_name()
3. Register your interest in particular signals - dbus_g_proxy_add_signal()
4. Connect a callback function for receiving/processing received signal - dbus_g_proxy_connect_signal()
--------------------------------------------------------------


References:
1. http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures
2. http://live.gnome.org/devhelp
3. http://maemo.org/development/training/maemo_platform_development_content/plain_html/ (This one's is very good and most helpful resource)