Dbus for phonekit?

Honkela Jukka jukka.honkela at ixonos.com
Wed Nov 7 10:40:46 CET 2007

Hello all,

I promised to send this one piece of code already one week ago (on IRC), but ...
I haven't had much time lately to follow what exactly is happening at the openmoko svn repository because I've been busy, but I thought to send this example anyhow to get some reactions do you see it usable or not.

The example is about dbus for phonekit and how to integrate gsmd with it. It defines only an interface for pin setup and the code itself does not link against libgsmd, at this point it just tries to give hints how and where the integration would happen. Try to search for comments containing "lgsm".

I limited the example to be rather simple on purpose; defining a large interface at once is not simple, even though I have done some work related to that too already, but there are some larger scale design issues that need to be addressed first. One of them is synchronous vs. asynchronous... Dbus, by design, is such that all calls must finish first before any other method call can proceed. In practise this causes various problems when one is interacting with an asynchronous device, such as modem. Some operations on the modem are so slow that calling anything in synchronous way will cause the UI to freeze for a long time.

So, there are more or less two different ways to try to solve the issue:
1) calling the synchronous dbus methods via the async dbus-glib api
2) make all the methods return values by signals

Neither of the solutions are perfect. Both of the options will cause some headache for the programmer writing the ui. The first option has the problem that things that cannot wait have to be implemented in a separate object/dbus connection. Things like doing hangup because othervise some other currently running AT command might block all Dbus activity. The latter version allows doing immediate handling because none of the method calls should last longer than few milliseconds; only the return values will be signalled back a bit later on, whenever the result(s) are ready. The biggest drawback with this is that the interface will become somewhat messy, although there might be some ways to reduce that.

The requirements to build the example are libdbus-1-dev and libdbus-glib-1-dev and it can be built in a normal linux development environment. The README file contains some hints how to try out the example.


Jukka Honkela

More information about the framework-devel mailing list